Making Good Software

Micro optimizations are one of many different bad practices that can be found in a project.

Micro optimizations are bad responses to potential or real project issues, they are created when the team fails to identify the root causes and instead they address the consequences, this usually happens because:

1. Urgency. Not enough time and resources are used to analyze the issue.
2. Experience. The patch strategy is always been followed.
3. Fear. Sometimes people know what the root cause is, but they are afraid to mention that.

Micro optimizations are bad because:

1. They switch the focus of the team from the big picture, they provoke the “Can’t see the forest for the trees” effect.
2. They provide partial feedback.

Micro optimizations are usually implemented as check lists, metrics, reports, documentation or some sort of paper work that needs to be approved in order to move forward.

Some common scenarios of micro optimizations that I have myself observed are:

• Because of the high rate of defects, the team decided they had to freeze the development from time to time and wait for QA to pass complete regression tests. This turned out to be a micro optimization and didn’t help at all. The root cause for the high rate of defects was that the source code quality was very poor, which in turn, was caused by a complete lack of experience and knowledge on the team on the technologies used for that particular project.
• Because of low productivity, management decided to hire more people for the project. Again, this turned out to be useless, the root cause for this issue was that development and product owner were not collaborating as they should, and as consequence, development never understood what was really required by the business.
• Because of poor performance, the team discovered that the bottleneck was on the messaging layer, so they decided to expend lots of money in a commercial solution that delivered better performance, this turned out to be a micro optimization and the performance issues came back. The root cause was that the overall architecture was poorly designed.

To avoid micro optimizations, focus always in the big picture, not in the details; use an out-of-the-box mindset. One helpful, very well known and very simple technique to avoid micro optimization is “the 5 whys technique”, this technique is better demonstrated with a sample.

The team only deliver half of what it was expected for the deadline. (The issue)

1. Why? They didn’t have enough time
2. Why? They had too much work
3. Why? They failed to estimate how much work they could take.
4. Why? They thought that the required activities to complete were simpler.
5. Why? The requirements were not detailed enough.

Avoiding micro optimizations doesn’t mean that the aspects they would usually be focused on, as: performance, punctuality, code coverage… are not important; it means that they serve to a higher purpose.

The biggest effect on moving away from micro optimizations is that you are likely to find that your main issues in your project are not technical, so probably you may want to take a complete new approach on them.