Competitive refactoring definition
Refactoring is nothing more than a way and a technique to keep the balance enabling the continuation of all activities. But what is the balance? Emotional one? Certainly also, because it is easier for us when the code we write is readable and testable. We are also more comfortable when the code is clean, extensible and works in accordance with business requirements.
Production and production capability
549/5000The most important balance that refactoring can make is the P / PC balance. LItera “P” from English symbolizes the word production. Production is the amount of money that we earn TODAY by providing customers with business value. “PC” (production capability) symbolizes the production capability, ie whether we will still be able to deliver business value TOMORROW. And tomorrow new requirements or changes to the existing functionality might arrive. It may be necessary to correct errors found in running software.
Let’s take a closer look at what happens when the above balance is not kept.
What will happen when only business quality matters?
This is the most common case, usually derived from the company’s value, that “the customer is the most important”. Unfortunately, it is very often associated with the creation of programming as soon as possible, with “excessive deadlines”, and therefore with low quality. This approach allows you to earn money temporarily, but technical debt always grows inexorably. Sooner or later (and usually much earlier than we expect) it will be very difficult to add new functionalities and change existing ones. It will become impossible to quickly correct the errors found in the software.
Due to the rush, the complexity of the solutions will become more and more, so over time developers will start looking for a new job. Those hired in their place will work for a while (probably for more money) but when they figure out what the software development process looks like and they lose hope. After a while, they will find that their nerves are bad. Ultimately, competing quality-conscious companies will be faster and more effective in the long term in delivering a competitive product.
And what when only technical quality matters?
By writing this blog, I want to be honest with the other party. What happens when quality counts “too much”? We can end up with a product of very high technical quality, written in accordance with all standards such as SOLID, DRY, TDD, KISS, BDD, TDD … (the list is probably long) but with little business value that will not allow the company to earn money and thus survive .
Maybe a balance?
So I will write with responsibility: although the quality of the code is important, it can never be an end in itself. The goal of programmers is to earn money and quality is to help (only and up to). Pragmatism above all!
So where is the truth? As usual – in the middle. Both sides (business and technical) must trust each other, help and cooperate. Each side should allow the other side to tip the above scale in the opposite direction depending on the situation.
Sometimes we need to deliver a product quickly to start earning money and using it to then take care of the technical debt (as with a bank loan). Sometimes we need to wait with the delivery of new functionalities because the technical debt makes it difficult for us. And then, after receiving new requirements, architects and programmers must take care of changing the architecture, packages and tests in order to prepare the project and code for new extensions.
Food for thought
Have you ever wondered how much balance refactoring can bring to lots of aspects like your…
- company ?
Why did I (maybe suprisingly) put company at the end of the above list? Share it in the comments!