Your company is in debt (technically)
Technical debt. Yes, there is a debt in the technical part of every project. The moment you start a new project you are already in debt.
Usually people don’t think of the future while creating a new project. The less you plan and architect a solution, the more technical debt you get. But on the other hand, the more you plan, the less chance you get of having some real-world feedback from getting into your company or idea, or project.
So, the solution is not in either of each one of the edge cases. I’ve had the opportunity to see both sides. Here are my thoughts:
Companies and projects with technical debt
The technical debt is so huge, developers cannot even move a single line of code without the chance of braking the entire functionality of an application.
That application is rigid, a monolith, immutable, unchangeable, and easily can become like a drug to an addict. Its maintainability will come at a high cost: your developers mental health and your business profit.
Bugs are everywhere and any change introduces collateral damage, no matter how small it is. Unit tests (and any kind of tests) are completely absent as well as quality and standards, there are no coding guidelines, and there is no documentation at all. The only person (s) who knows it is a single developer, usually the one who created that piece of spaghetti. New developers will have a very hard time to figure out the bunch of spaghetti code, and will probably leave the company in the next two to three months (the most) after being hired.
This can result in a very drastic waste of time and effort while trying to change things. Any change represents a huge challenge, the application is a bomb waiting to explode with the minimum change.
Companies and projects without technical debt
On the other hand we have companies and projects whose technical debt is either null or very little. These companies usually spend a lot of time architecturing their projects, and they have understood the art of avoiding technical debt so well that they even deliver faster and more efficient code with every iteration.
There is usually a lot of documentation, the project itself is very well tested with a test coverage that surpasses the 90%. New developers can start to code right away by only reading a couple of summaries regarding the application architecture, and are eager to leave the table cleaner than they found it. They are even eager to explain the architecture to other developers and are usually proud of their job.
Developers in this kind of companies are usually thrilled about new challenges, they can focus on abstract thinking rather than in concrete thinking and can also contribute with more great ideas that are going to add even more value to the company itself.
A drawback is that this comes at a very high price, and this price has to do with having to wait longer than any other company to deliver something that can actually add value to the company’s clients.
The conclusion
Get in debt only when necessary but make sure to payoff as soon as possible.
The good management of technical debt is just like a credit card: you may want to use it, but pay what you get as soon as possible in order to avoid high interest rates from drowning you in debt in the immediate future.
Throughout my years as a software developer I have came to the conclusion that none of the sides are good if you take them in the extreme sense regarding their meaning. Every extreme decision can create extreme results, either bad or good. The key is to be pragmatic, and pragmatism doesn't really come during the night.
