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.

você pode gostar também