Where to start a project

Novices daydream

In architecture school, we were taught to design and build things very differently from the technique engineers often use. The process we followed consisted of iterating many times on a single idea.

At the beginning, the first thing most students want to do is sit and think. The professors see you daydreaming, stop you, and tell you to start drawing. Some students try to take a shortcut: "I'll just think it all out first, so I only have to draw it once." That never works.

If you spend an hour drawing — even if it's mostly garbage, and it will be — the time you spend thinking about the thing on paper gets you much further than the time you would have spent only imagining it. So you sketch, on rolls of the cheapest paper you can find, and by the end of however much time you've spent, you have a few real ideas for the design.

The next pitfall comes here. Designing spaces, you've been thinking about the problem in two dimensions, and you've almost certainly missed something that only shows up once you move into three. Time spent making nice, formal two-dimensional drawings is still a bit of a waste, so the professors have you build a model instead. Not a nice model — cheap, fast, crummy models that only a mother could love. That forces you to confront the design more realistically, and reveals the awkward corners a drawing never would have shown you. It moves the design forward. Before you spend real time on a polished product, you need to sketch it out first.

Waterfall

The software industry has been figuring out its own version of this lesson for decades. Waterfall is the equivalent of daydreaming it all up and then drawing it once: think up everything the software will do, lay it out, assemble a team, build it, and move into maintenance. That way you only build it once.

It doesn't work for the same reason the daydreaming shortcut doesn't. The transition from a flowchart to real code is exactly like the transition from a 2D drawing to a 3D model — you've missed something. The design wasn't as flawless as it looked on paper, and the elaborate timeline is now wrong because something has to get hacked in to compensate.

Lean, agile, MVPs

The current movement is at least aware that elaborate upfront designs and timelines don't hold up. That's progress. As quickly as possible, you assemble all the moving pieces so you can actually see the awkward corners and edge cases you didn't anticipate. Then you get it in front of real people and start gathering data on how they actually use it — which surfaces another round of edge cases you didn't see coming either.

Brain to paper to model. Brain to code to users.

A good product also doesn't try to do everything everyone could conceivably imagine it should do. Don't get bogged down imagining every hypothetical scenario; focus on the simplest possible iteration you can put in front of actual people.

The code is a mess

Oh no, organic code! Everything's hopeless!

If this is genuinely the first time you've built this thing, that's fine — you were never going to get it right on the first try. You have work left to do, but none of it was wasted.

Start by looking at the places where you've repeated yourself. Those patterns tell you where the real structure of your code should live, and what layers of abstraction are actually necessary — you'll know you've found the right one because it makes your life easier. If you wrote the same thing a few different ways while you were still feeling it out, go back and pick the best one, now that you're actually in a position to tell which one that is, and normalize the rest of the code to match.

Gather up whatever notes and half-finished ideas didn't make it into the first version and put them into a real tracker. Don't start a project with a ticket for every last thing you plan to do — but do consciously switch into that phase once you start putting the thing in front of users.