Build It Twice

Something I’ve experienced and also seen repeated before is the notion that a big software system has to be written twice. Or, equivalently, refactored mercilessly until it’s been replaced entirely with something new as in The Ship of Theseus (wikipedia.org).

In fact, while reading interviews with the "old masters" of programming (such as in the books Thinking Forth and Masterminds of Programming), I’ve found my own experience echoed by people who are generally considered to be profound thinkers.

It turns out, nobody is smart enough to get big, complicated systems right the first time.

And even if you did build it perfectly, you’re gonna find out that you built the wrong thing. Because nobody gets the requirements right the first time either!

And even if the requirements and the implementation are perfect, the needs will simply change over time.

This is something Steward Brand hits on in his incredible book about physical buildings and architecture, How Buildings Learn. It’s not good enough to make the perfect building (as if that were even possible). You need to make a building that is fixable and flexible.

And it seems that the only sure-fire way to do that is to build simply and durably. Modular, testable code is one way to go about this. Pure functions and immutable data seem to be another. The easier it is to replace something and test that its replacement is correct, the better.

In the software business, I wish we would just embrace 60+ years of software development wisdom and insist that clients knowingly pay for two copies of most programs: the first would be the working prototype and the second would be "doing it right" once the prototype has been beaten to pieces and abused by the people actually using it day in and day out.

The first copy would be ugly as sin, but fully functional.

The second copy would be the one that gets the final, polished source comments, READMEs, and user documentation containing the wisdom gathered in building, using, and abusing the prototype. And now is the time to make it pleasing to the eye as well.

Instead, we always pretend that "this time will be different" and that we’ll somehow fix it as we go using "agile" methods and arrive at something perfect in the end. As if.

Closely related: Do it the dumb way first.

And on a smaller scale: Leopard-Free Programming.

"Back" to programming.