managementI decided to write this blog post after reviewing this pull request. What happened there? The author of the PR wasnât able to figure out the ârightâ way to implement it, and the code reviewer was waiting and waiting. Eventually, the reviewer came to me, since I was an architect, and complained that it was taking too long and he wasnât able to earn his money for the review he had done. Then the author of the changes explained that he couldnât finish since there were impediments and design inconsistencies; he also couldnât earn the money he deserved for fixing the issue. What did I say? I said: Forget the quality, just finish it any way possible.
Was I kidding? Not at all.
I truly believe that quality is not what programmers should care about. They must care only about speedâclose tasks as soon as possibleâ which means make money.
Wonât this attitude ruin the project and turn the code base into a mess?
Yes, it will.
If the project doesnât care about its quality either.
There must be a permanent conflict between a project and its programmers: 1) the project must be configured to reject anything that lowers the quality of its artifacts and 2) programmers must be interested in making changes to those artifacts. The project cares about the quality, the programmers care about fast delivery of modifications.
What do I mean by saying that a project rejects low quality? Here is a list of preventive measures it may take to make it impossible to jeopardize the quality:
- Automated pre-flight builds;
- Read-only master branch;
- High test coverage bar;
- Mandatory static analysis;
- Multi-step code reviews.
What do I mean by saying that programmers must be interested in making changes? They have to be motivated to close tasks. Not just to be in the project, but to deliver. Here is what they can do in order to close tasks faster:
- Cut corners;
- Make changes smaller;
- Donât study the code, just modify it;
- Donât feel responsible for all code, just focus on the relevant units/classes;
- Donât be afraid to break things.
If we put these two interests in conflict, we will get a high-quality product, which is growing very fast. The project will enforce quality, programmers will push the code forward, making changes fast and frequently.
Unfortunately, most projects have a very different philosophy. They delegate quality control to programmers, hoping that they âwonât do evil.â This leads to frustration, distress, constant fear of mistakes, long delays, blaming, and shaming. Both the project and its programmers lose.
Programmers must not be responsible for the quality! They must not care what they may, or will, break. They must not care how good the code they write is. They must not âfeel responsibleâ for the overall result. Instead, they must be focused on making money for their families by writing the largest amount of code and closing more tickets.
Not because they are ignorant and selfish, but because this is the right balance of responsibilities. This is how the project will get the most out of its developersâby freeing their minds of unnecessary and unproductive quality worries and letting them focus on what they do bestâwriting code.
Of course, not every project will be able to configure itself in the most effective way. Most projects donât even know how to do it. In those projects, if you, as a developer, floor the speed pedal, you will most likely ruin their code base in a few days. Thatâs why the recommendations above are only applicable to those who really know what they are doing.
We know what we are doing in our projects. We donât let any developers touch any parts of our code, unless the âquality wallâ is high and strong enough. How high is that wall in your projects? Can you say that, no matter how bad some code is and how sneakily its author introduces it, it will be rejected?
