Ignoring technical debt doesn’t stop it.
“If left unchecked, technical debt will ensure that the only work done is unscheduled work!” — Gene Kim
Technical debt is the dirty secret that no one wants to acknowledge. Like an embarrassing parent no one talks about. Projects ignore it and push issues to future dev teams and hope it’s not them.
The quick wins of ignoring technical debt end up becoming the tragedy of the common scenario of a big loss in the future.
It’s not just development teams that ignore technical debt, but software development denies the existence of technical debt. Technical debt is the problem that should not be named, the Lord Voldemort of software development.
The common goal in software development is the short-term creation of software. Software development is misunderstood, it is not the speed of creation that is essential but the quality and the minimization of the technical debt.
Quality is the fastest way to get code into production.
Ignoring technical debt is like assuming your tools will never wear out or need replacing. If your job is to fell trees with an axe, you need to sharpen your axe; otherwise, it will slowly take longer to fell a tree.
Development teams either ignore the fact that technical debt is inevitable or deny it. Every development team knows tech debt is bad and knows they need to avoid it, but 99% of them have no plan for it and don’t mention it until it’s too late.
- Developers who don’t know what technical debt is have no chance of not creating it.
- Those who know about technical debt but do not take steps to avoid it will create technical debt.
- Development teams that put in place quality steps to prevent its addition (rules, processes, standards, code reviews) will keep most technical debt at bay but cannot prevent it from sneaking into the database of code.
Creating software and writing code in an agile approach will create technical debt, its inevitability. The long-term effects of technical debt are bad. This creates more complex code and slows down the development team in the future.
Few development teams have a process for identifying technical debt and fixing it. Many development teams ignore technical debt, the majority submit to the inevitable fact that it will grow, but how many have a plan to reduce technical debt?
If development teams know that technical debt is inevitable, then not having a plan is to deny that it’s a problem. Technical debt is put in the too-hard pile and left for someone in the future to deal with.
I use the term legacy code to mean that the code base has reached a state where the team has given up the battle against technical debt. Cleaning up the code would take too much effort and it’s not worth it.
The development team uses an all effort attitude of trying not to make things worse and occasionally cleaning up areas where you can safely update it without breaking other areas of the code and if time permits.
The second law of thermodynamics states that the total entropy of a system increases or remains constant in any spontaneous process; it never diminishes. 12.3 Second Law of Thermodynamics: Entropy
Things start in an orderly state and become less orderly. It’s easier (takes less energy) for something to become less orderly and there are more ways to become less orderly.
Keeping things in order takes more energy than messing them up. Ask any child to tidy up their room and they’ll tell you how much extra energy it takes to tidy things up.
A codebase degrades over time unless energy is diverted to keep it in order.
How to get a base in a legacy state and a complete mess? One record at a time🙂 — How to prevent developers from creating legacy code.
How is a project a year late? One day at a time.
The more code developers add, update, or remove from a code base, the messier it gets.
When I view technical debt, I see if instructions are inserted into the code to fix bugs or add new features. It’s like extending an existing house and ending up with a bedroom that can only be accessed through a bedroom. No one would design a house like this, but it’s a cheap solution for extending an existing house.
Technical debt is an inevitable part of multiple developers with different skill levels working on the same code base using an agile project methodology.
A common cause is agile development. Drip feed features/requirements cause additional functionality to be added to existing code that you couldn’t foresee in the original design. Development teams find themselves in the difficult position of adding new features that should work with existing features, but were never originally designed to do so.
Time and delays create technical debt. Development teams don’t have time to redesign code, so they have to push square pegs through round holes.
If the development teams know that technical debt is going to be created, then why is there never a plan to fix it?
Most projects do not have a plan to address technical debt. Practices are put in place to minimize technical debt such as:
- Automated rules
- Control tools
- Code review
Good practices slow the accumulation of technical debt, but they will not stop it completely.
The code deteriorates over time, becoming worn and baggy like clothes. The original code design is stretched and twisted as developers attempt to fit new features and bug fixes into a code base.
At times, it needs to be streamlined to take multiple designs and make it into a cleaner, more logical design. Like removing unnecessary phrases and words from a document. This process brings clarity to the code and simplifies it.
The removal of technical debt has no immediate benefits. The benefits are long term. This doesn’t fit the short-term nature of software development today which only focuses on building software but not maintaining it.
Maintenance costs are future problems that will belong to someone else.
Companies complain about the cost of creating software, but they cost themselves more by creating software that is difficult to maintain. Supporting legacy software is harder to do, more error-prone, and stressful.
The goal is to build software as fast as possible and not worry about quality. Most people know that if you pay for cheap things, they don’t last.
If you create shoddy software, it’s hard to maintain and nobody wants to maintain it. Software is a long-term investment, so aim for quality and reduce technical debt. Investing in quality software is a long-term investment.
More content on PlainEnglish.io. Subscribe to our free weekly newsletter. follow us on Twitter and LinkedIn. Discover our Community Discord and join our Talent Collective.