Something that will make software projects go way better down the line: Build the first version — a rudimentary version of it — three to five times, from scratch.

Each time, build in a different way, a different software stack, whatever — just use what you’ve learned to try something you think could be better, or take a stab at a way to build it that seems absolutely wild, even if only to prove it isn’t the right direction (quite often, yet still unexpectedly, these become the clearly best direction).

Forcing yourself to build the fundamentals five times over lets you very quickly iterate on insights, evolve early concepts, test if your choices are actually best (versus just good enough), plus try a few wild variations, and it allows you to simplify the core constructs now that you understand them better.

And since quantity is the journey to quality, you’re engaging in the best known practice for making something great.

The best stuff is made of lots of basics. Building and rebuilding lets you discover the fundamentals, then — importantly — rebuild the foundation based on those fundamentals, which you can then stack together to build something solid from the beginning.

Writing and rewriting the fundamentals has helped me to see completely inverted ways to build things which, often times, turn out to be far superior even if completely non-obvious at the outset. This has certainly happened in Lab Note 001: Building apps in minutes, not months, which explores an inverted app architecture to shave off most of the development time.

Hamming discusses this in You and Your Research:

When stuck, often inverting the problem and realizing the new formulation is better represents a significant step forward.

Richard Hamming, in You and Your Research (PDF)

(I highly recommend reading the linked excerpt — it is only a few minutes long.)

Number 40 on Akin’s Laws of Spacecraft Design:

[40] (McBryan’s Law) You can’t make it better until you make it work.

This might be the fundamental issue: if your production version is the first attempt you took, it may work, but there is a very low chance that it is the optimal solution, since you didn’t take the opportunity to make it better in the many ways that are only possible once you’ve first made it work.

Number 14 on the list also comes to mind:

[14] (Edison’s Law) “Better” is the enemy of “good”.

Similar discussions

In When Understanding means Rewriting, Jeff Atwood wrote a fantastic discussion on this.

I think the way most developers “understand” code is to rewrite it.

From When Understanding means Rewriting, Jeff Atwood

Further on Akin’s Laws of Spacecraft Design, you can see this concept come up multiple times, in various ways:

[3] Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.

[9] Not having all the information you need is never a satisfactory excuse for not starting the analysis.

[11] Sometimes, the fastest way to get to the end is to throw everything out and start over.

[12] There is never a single right solution. There are always multiple wrong ones, though.

[14] (Edison’s Law) “Better” is the enemy of “good”.

[31] (Mo’s Law of Evolutionary Development) You can’t get to the moon by climbing successively taller trees.

[35] (de Saint-Exupery’s Law of Design) A designer knows that they have achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

[36] Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.

[40] (McBryan’s Law) You can’t make it better until you make it work.

[41] There’s never enough time to do it right, but somehow, there’s always enough time to do it over.

[43] You really understand something the third time you see it (or the first time you teach it.)