Technical debt is an organizational crisis.
Today topic is about some technical debt your product might have. One of the most frequent responses I got, when suggesting to eliminate the tech debt, was:
But we are fine, we’re doing like this for couple of years already!
In other words, it is more comforting for all involved parties to accept technical debt like we accept some bad weather than fight it like we fight some clutter on a workplace. The only problem here is that after a certain amount of technical imperfections they create a technical debt, which brings in some maintenance costs, delays, unnecessary complexity in new features implementation just to bypass existing limitations tied to technical debt and etc.
I’d like to compare technical debt situation with some chronic disease situation. If there are hundreds of thousands people sick with tuberculosis, it doesn’t mean that it is fine if you got it too, right?! Or if you living with some chronic disease, it doesn’t mean you became a healthy person, just because you have it long enough. The same is with technical debt — if your organization has learned to live with it, it doesn’t mean that situation is normal or acceptable.
I’ll put it simple — technical debt means your organization is in crisis. I don’t mean if there are some technical issues, because every product might have ones. And if your organization is able to overcome them — everything is fine. But the tech debt looks different. When old technical issues are causing some new ones and no one is going to solve them, it is a constant fight to add something new to your product — this is a tech debt and this is a crisis.
Signs of organizational crisis.
First you allow your technical issues to pile up in a product and very soon you find yourself in “brown field development” mode, when developers are standing knee-deep in manure, but they used to the smell, used to move as fast as turtles and everyone finds its convenient to justify ever-growing amount of tech debt by system’s complexity.
It is fine if you have your technical debt, but it’s not fine if you are making it is bigger with every release — it’s a law of economy, that bigger debt requires bigger interest payments, which means more efforts would be spend on tech debt maintenance that on new features development. It’s like you’re rowing on a leaking boat but refuse to fight the leaks instead of focusing on getting faster to your destination. In short term this strategy can work, but trying something like this in mid-term strategy will bring you not to your destination but to the bottom of the sea, no matter how fast you’ll row.
Sometimes I hear self-comforting speeches like: “Yes we have a technical debt, but it is not that big as you’re saying…”. The answer to that is simple: if you repeatedly can’t deliver on time what’s been promised — your technical debt is big enough.
So, if your management accepts that technical debt exists, but refuses to acknowledge the significance of debt elimination, the situation your project has got into could be described as a constant lagging.
When you management or business owners refusing to reach some compromise with technical experts on how much efforts should be allocated for debt’s elimination they are putting both parties into constant lagging crisis. That means if the parties argue long enough on how much efforts must be spend — the situation is getting worse. And when (or if) parties reach some agreement in a situation of crisis — it won’t be enough. Just because, while they were arguing situation become worse. Spend more time discussing — it will get even worse.
Often long discussions are caused by wish of stakeholders to get some assurance that situation will become better than now. That is a false hope. The only assurance can be provided there is that if you do nothing it will become worse. Every line of code added into dysfunctional product increases it’s technical debt.
Sometimes stakeholders want to discuss everything onshore, before they green-light debt elimination. That is also a faulty strategy. No one can estimate (NO ONE) how much time you need to spend to unpile the pile of manure, which was built by many people for many years consequently. The only prediction could be made is about how soon your product is going to become completely unusable, obsolete, unmaintainable.
What to do.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
Conway’s Law from “The Mythical Man-month” by Fred Brooks
If your current way of doing things has got the organization into a crisis, it is quite naive to think, that something can be done without changing the way of work for the whole organization, like hiring more people or bringing on-board some development rock-starts from a consulting company.
Usually, there are three thing, which contribute to tech debt the most:
- External pressure on a team (no time for writing tests).
- Bad or chaotic processes (ad-hoc features in the middle of the sprint, testing sprints, badly crafted user stories and etc.).
- Not enough skills to produce software with good quality.
These are things you need to address in order to fight the debt. Lower the pressure, design your processes and align them with developer’s skills. Find what skills are missing in the team, start to develop them. Not always these things are purely technical. Lack of decision making ability or collaboration skills also affects size of your tech debt.
How to fight it?
So first thing to do is to stop producing more tech debt. Split the parts of the system, which are damaged beyond repair and these, which could be reworked into something more robust. Add new functionality only into parts, which you plan to refactor.
If adding something completely new, better to create a new system aside to an old one. Do not let new one’s design to be affected by old system’s design.
Old systems in “beyond repair” state should be rewritten and decommissioned. Good thing is to review the solution old system provide and optimize it to present day’s reality, not just replicate the old logic.
The main idea is to move forward technological and organizational improvements both simultaneously.
