How Experienced Developers Can Handicap a Lean Startup

Trying to be industrial strength for a proof of concept or an experiment is typically a junior's mistake.

Wouldn't it seem to be a mismatch from the very beginning?

Bear in mind that if you screw up hard enough there's no guarantee you can recover. Anybody hanging around this site for long enough has read at least a couple of stories about the technical error that brought the whole startup down because there weren't enough resources to recover, and "botched database upgrade" (combined with "failure to backup", which of course occurred because there was no time, we're going too fast and we're too awesome!!! to do the backup) is a prime candidate for that sort of event.

I say the latter because I've been there. Setting up foreign keys is one skill. Learning how to migrate them is another. I've screwed it up before. It does take a bit of learning. But once you learn it, you're still better off using them properly in the first place. There's also some skill in learning how to set up your database so it can be migrated; I'm not even sure how to begin putting it into words, but there's definitely some skill involved there. (I'm not guaranteeing I've got it all figured out, but I've certainly improved, which is enough to establish that it is a skill.)

They're not equivalent either, certainly, but when you say "orthogonal", you're making the claim that they are not just different (which is true), but utterly unrelated, and that claim is unsupportable. I've been deliberately spending my last couple of years learning how to build things both fast and right, and I've gotten to the point where I can spank anybody just "hacking around" after about a two-month window, after which it's all profit. In fact I'm building a system replacing just such an effort right now... well, after I stop posting this anyhow. My system isn't a glorious paragon either because as an experienced developer I know where to cut corners to get it out, but it's a lot stronger than the hack job it's replacing (and I'm doing it in less time, too).

(Part of the reason I started this learning is that I was at a startup where I did in fact make this exact error. In the end, this is not what killed it (what killed it was the management insisting that there was always just one more feature we needed before release, and then once we had that, there was just one more, repeat until out of money with no customers), but I've made this mistake and I won't make it again. But the alternative is not hackhackhackhackhack, the alternative is being more familiar with the cost/benefits ratios and picking the winners, some of which will still be "do it right", and some will not. Hardcoding the answer in either direction is wrong, as it pretty much always is.)

I want to iterate on my game's level design abilities to choreograph various enemy AIs with detailed scripts - things like "this group will spawn over here and take this path over there, shooting at these intervals."

But figuring out what the best paradigm, the best data format and tooling to help me iterate on the choreography is - is a guess. I can make a bells + whistles solution, but it might not be the right one. But neither is it something that can just wait and becomes obvious at some later date - the technical solutions and the design solutions are intermingled and have to be resolved together. So even though I'm my own customer, I'm still in the "lean" stage of this feature.

So I'm trying to stick hard and fast to "stupidly simple" means of tackling each problem I encounter. Instead of making one all-powerful choreographer system I've started with the stupidest, simplest one I could think of, hedging my bet by allowing multiple systems to coexist, while making the key pieces of data I already know I need, like spawn positions and trigger targets, sit in a different layer where they're easy to edit and interchange.

Essentially, I want to ride on the "80% solution" for a while and then gradually accumulate the rest, and I think the key to making that work is to know where you are uncertain and start fencing off the most suspicious areas so that you can build the eventual shift into the architecture - not modularity so much as "this code will someday become legacy code, so treat as if it already is."

I'm really sleepy right now so this might seem more profound to me than it is.

I'm just talking about the technical approach. You've gained no new insight into what your business is supposed to be, you've just learned a hella wrong way of solving a technical problem. Now your thoughts are cluttered with the effort and you had to spend time unlearning the previous approach.