Everything has its life-cycle. Even stars. Even The Universe. Everything.
It is quite sad for intelligent creatures, but it is just a fact of life. I want to draw some quite obvious parallels to reveal the real danger of Technical Debt for a software product.
Let's take a human. When we are young, we are overflowed with energy. Do you know how a 7 year-old boy spends his day? I have a son, so I'll tell you. He wakes up at 7 am (sometimes before 6 am!) and tries to play some quite silent games (it is too early to make much noise). He can restrain himself till about 8 am, then he starts to jump, does somersets, some boxing etc... By 8.30 we have a real "tornado" in our house. It may take him an hour to exhaust and have a breakfast. Such periods of activity can be easily repeated 2-3 times a day. And he literally turns off around 9 pm - sleep is when he recharges his batteries.
An old man is quite the opposite. He saves every movement, everything is hard and slow. He makes many mistakes and health maybe getting worth. Learning new things is also getting harder at times. Yes, wisdom and tremendous life experience is there, but very often there is no energy to move forward.
But what's next? Years later progress stops. Product becomes old with all the bad and good side-effects. Suddenly it is much harder to add new features. Ages of development make the product more complex. Millions of technical debts rotten its body like cancer . There is no clear architecture anymore and there are so many patches that one small change can produce a totally unpredictable impact and bring along new bugs in unexpected areas. Yes, development team has wisdom. But often no courage and energy to revive the product.
Technical Debt Is a Cancer
How long does this cycle last? It really depends. We all visit doctors. Most of us want to live longer and healthier. Early cancer detection gives good chances to fight and win the disease. We should do exactly the same with software. Here are typical symptoms:
- Velocity has dropped significantly over the last several iterations/releases
- A bug fix triggers one or several new bugs too often
- Nobody knows ideas behind the original software architecture
- Team spends more time fixing bugs than developing/improving features
- Automatic tests are red 80% of the time (if it is 100% — the product is most likely in coma)
If you see at least 2 such symptoms, you've just discovered a product cancer — Technical Debt. Technical debt is a true killer when you have deadline (time to market). If you have the symptoms, you should fight the disease right now. You may think that it is OK to wait several months, add some more "cool and highly requested" features and then get back to the real problems. It is a wrong decision, believe me. I used to make it and I used to fail with it. It bogs you down. You lose focus and make stupid mistakes. It leads to fear. And fear is a bad ally. You go from one extreme to another to only increase entropy, nothing else.
If you miss the deadline, all the possible actions will not help. Cancer will win. And then you will have just two options: re-write the product completely from scratch or start a new product.
If you see these symptoms, you should stop and think about the attitude of your development team. If you've survived over several years, priorities should be changed. Reset your development team and use chemotherapy.
- Focus on quality. Fix the roots of the problems.
- Teach the original architecture to all, pair program, communicate.
- Introduce "No new code without tests" rule.
- Fight fear. Let the knowledge spread. Knowledge eliminates fear.
- Put the most experienced people on fundamental problems solving.
You have to fight the cancer to bring energy back, to bring courage back, to live and produce a great software product. Otherwise it will be as dead as Lotus Notes.