The make it work, make it right, make it fast misconception

On the agile way of doing software development, one of developer’s favorite mantras is: Make it Work, Make it Right, Make it Fast.

However, it’s not uncommon to see people complaining that by following this directions, their project never get to the make it fast stage. That happens because of a misconception where people treats these three steps as isolated actions of a project. And they are three stages of one development task.

While you start a development task, you have an early stage where you need to explore possibilities. You don’t quite know what is the best approach but have some ideas. If during that stage you go big looking for THE piece of code that will fit the problem perfectly, you will end up spending a considerable amount of time on that quest. That’s because you have too many uncertainties on your solution and you need to discover through experimentation to reduce those uncertainties to a comfortable amount so you can focus and implement your code. This experimentation process is the Make it Work stage where you just code to achieve the desired behavior or effect.

Just after that, you’d probably discovered what kind of libraries you will use, how the rest of your code base interacts with this new behavior, etc. That’s when you go for refactoring and Make it Right. Now you dry things out and organize your code properly to have a good design and be easily maintainable.

As Software Developers, we know it’s true that restrictions are everywhere. And for this we know that there are tradeoffs between design and performance. This is when you go for the last stage where you Make it Fast by optimizing your code to achieve the needed performance. By doing this at this point, you will see that it will require much less effort. That’s because you can focus on the small 20% of code you can tune to end up with a 80% performance increase.

Ending all those three stages, you will reach the end of your development task and can integrate this code into your project, delivering the desired value to your Product Owner.

If you ignore one of those steps while you’re coding that one task, you will probably suffer the effects of doing big design up front, increasing technical debit, and having a awful system performance.

That said, a last piece of advice: Be careful not to compensate bad time estimations delivering code that only “works”. If you do it as a rule, I assure you that you will end up with some non-tested spaghetti project where your cost of change will be so high that can put your business at risk and make your “agile” useless.

  • Yeah, I tend to agree – all three of these “steps” can be seen as a sequence of one single step in development. Treating them separately can easily allow other projects to take focus, reducing the likelihood that “make it right” or “make it fast” ever get reached. Lots of experience in programming can allow for “make it work” and “make it right” to happen simultaneously, especially with a high degree of familiarity with the system. Never reaching “make it fast” is a guaranteed way to hit a wall of “slow” for the whole system at some point in the future, and those things tend to rear their ugly heads at the worst time possible. Consider all three phases necessary for release!

  • JimTheMan

    Great post. I agree!

  • Pingback: The Problem with Layers | ITJUMPSTART()

  • I think part of the misconception is due to the fact that one of the steps for TDD, for example, tells you to “code the simplest thing that could possibly work” (make it work). However, most people just ignore the refactoring step that comes after that (make it right / fast) and leave their whole codebase as the “simplest thing that *surprisingly* works!”.
    The Software Craftsmanship Manifesto ( addresses that problem really well: it’s not about making it work, it’s about making it right!