Throw away your prototypes
Woof. Writing this right now from my office – the only room in my house that hasn't been torn apart by the move. The rest of it – disaster zone. We had movers on Friday and they took the big pieces of furniture and ~15 other boxes.
Now there's just the rest of the miscellanea to move, and my office. We have until the end of July, and we're taking advantage of the overlap. It's kind of nice, now. We have all the main stuff in the new place, we can live there, and everything that's there is in a potentially final place – no great snowdrifts of boxes waiting to be unpacked and arranged. We've got time to consider the rest of it. Find actually good places for it.
This is Nat Bennett, and you're reading Simpler Machines.
Two things you should be doing if you want to turn out more and better technical work:
- Design by building prototypes
- Throw those prototypes away and rebuild them as production code
Do not skip step two.
Step one is important because it prevents designing stuff that can't or shouldn't be built. I see this a lot with "design document"-based processes. Folks will spend weeks on gigantic documents, writing them, reviewing them, arguing about them, that turn out not to meet basic requirements. Actually building a basic version of the thing gets you into contact with reality way faster.
Prototypes also really turn the temperature down in technical conversations about the design. You're talking about a thing that is rather than a thing that could be and somehow that makes everyone more chill. Fewer misunderstandings, fewer arguments about what something "means," more objective discussion.
The trouble, of course, is when you put that prototype into production.
It's always tempting. It works! You just put so much work into it? Why waste time building "basically the same thing?"
But. The second time you build the thing – or the third time! – it will be much better. You'll be building it fresh with everything you learned from the prototype, everything you learned from the discussion about the prototypes. The prototype probably doesn't have tests. The prototype may have made some decisions that make changing it awkward.
Also: Design prototypes tend to be the product of one person. Production code needs to be the product of a team.
One of the big themes of my career so far has been rescuing teams that have run aground, and getting them shipping again. These teams have some things in common.
The most common, by far, is the team that's struggling to support a prototype that shouldn't have been put into production. The code's not tested. (It was just a prototype!) It uses a ton of metaprogramming, or similarly trades off comprehensibility for implementation speed. (It made it fast to build the prototype!)
Once code has customers you lose the ability to throw away the code and start over. This is basically what legacy code is: Code that has customers, and is therefore hard to change. Getting customers on a system that's not ready for them can haunt a system for decades.
Also common, though, is the team that's not shipping anything because it's so focused on getting the design "right." Getting the abstractions "right." This is less common than the former in my personal experience, though, because these teams are less likely to get to the point where they have a lot of money but can't ship anything because, well, they don't ship in the first place. Gotta ship to get legacy code.