- The company sidelines engineering’s concerns as a nice-to-have.
- The codebase itself quite literally becomes a “difficult work environment”.
- It gets hard to recruit strong engineering talent.
- The company’s best engineers start to leave for blue-sky work at other startups where the codebase is more enjoyable to work in.
- New features start shipping very slowly. Or stop altogether.
- Gradual attrition of all engineers who like building things until only “maintenance-style” engineers remain.
- Company falls irrecoverably behind the times.
If you accrue technical debt without budgeting time and resources to pay it off, parts of the codebase become too unmanageable to modify. Engineering deliverables get smaller and less frequent.
Gradually customers experience the zombification of your product.
Eventually the codebase goes bankrupt. And the only practical choice will be to rebuild the entire thing from the ground up—something which very few businesses ever get a chance to do.
Is Bulb at point 5 in the spiral? We know that there is a huge discontinuity in the code base between service for SMETS1 and SEMTS2 smart meters. This is technical debt that was likely incurred when quickly developing test services for SMETS1 without knowledge of how SEMTS2 might end up operating. Well written code (often with the benefit of hindsight) wouldn’t suffer this, and it would be easy to attach the two systems to a common billing API and customer data visualisation API. Bulb clearly have a lot of work to do in paying off technical debt.
How long before Bulb gets to point 7? Are they already there? Just from posts on here, we know that one of their best devs has left (point 6?) which is what has resulted in the much-requested data API getting delayed indefinitely.