You probably have heard the saying “if you fail to plan, you plan to fail”. I get the sentiment here, when you have a task to do, if you don’t plan how to do the task, you are far less likely to be successful at completing the task to the satisfaction of the person requesting that task.  

But one thing of note here. You did make a plan. Just not a very detailed plan. But today I wish to share a different point. That being when you do plan, no matter how detailed your plan, you are still bound to fail, right? I doubt there is a sports team on earth that doesn’t have a plan, a well thought out one at that. Every game at least one team fails in the end.  So, you ask “If you are likely to fail either way, why bother?” Splendid question. And the root of almost any hot take in life, the answer comes from what you learn from the process, and in this case, the ensuing failures. There are many analogies in technology that are made with Lego.

If you have ever built with Lego, you know there are four general paths to build something. Now in each case, assume there is someone who will judge your work just as harshly as the customer who asked you to build a quality control system for their manufacturing plant.

1. Design as you go. So you down with a bunch of random Lego and just start connecting. Maybe you build something, maybe not.
2. Decide I want to build a castle. Build it brick by brick with no planning.
3. Design the unknowns. Draw out how you think it should look, the dimensions you want the castle to have, estimate the bricks and time. Make sure you know how the castle will be used (set on a shelf or in the hands of a child with a wonderful imagination?). Determine good breaking points to review with clients. Build sections and review.
4. Design the whole thing first. Still working on that castle, go one step further and plan out each section in such detail a small child could follow along. You know, like the illustrated instructions that come with a Lego set. Then start building.

Every one of these paths is bound for failure except the first. Don’t plan to build anything specific, and likewise, didn’t achieve anything specific. As a George Harrison song once said, if you don’t know where you are going, every road will get you there. This is not how any typical computer project works, unless you have venture capital sometimes.

As you move towards more and more planning to meet the need of a customer, the specter of failure starts to creep in. In the second case, you at least planned to build a castle, so what if you don’t achieve that goal. Failure. But consider case number 3. If you build in sections, and apply something at least close to Test Driven Development, you will find the flaws in your software in code, and your thinking via customer involvement. Every iteration, you are going to fail in some ways, and you will learn from that failure and try not to make that mistake again.

Learning from our small failures is why people have steered clear of number four (designing in detail and designing it all first) in recent memory. If you happen to be perfect, this would be the best way, figure out what the person wants, draw up all the plans and leave the builders out of it. But you know how that story goes…

Some basic mistake is made as you create that castle and it goes unnoticed for a year of coding.… occasionally the lesson you will learn will be that you have start over. Complete, detailed designs are only valuable for projects that have to be done over and over. And that Lego instruction booklet with illustrated steps to build a castle first started out being built iteratively.

The concept of iterating over a short time period works really great in any industry where undoing your mistakes early is doable. It is why Lego is a great analogy to computer programming in some cases. Tearing down mistakes is very possible, even it if start you tearing up. 

And here is the lesson you probably saw coming, you are going to have failures. Try to make them small and learn from them. Try not to do it again, and instead make different ones. And learn from them too. The smaller your mistakes you end up making, the fewer the eventual production users will live though.   

So lets rename it: “Planning, the First Step to the Right Kind of Failure”