The Crumbling Codebase
Does the following sound familiar?
🤔
Back when I extracted this module, it seemed like a good idea. What did I think I was doing?
🤹
The models in this namespace are so tightly coupled, it feels like I can’t move them an inch. Where’s Houdini when you need him?
🩺
The team that developed this feature is gone, and with them all the knowledge about it. Where do I start cleaning it up before I add more functionality?
If any of these quotes resonate with you, you are not alone. Here’s a harsh truth: Over time things tend to degrade. Memory, structure, cohesion are all subject to decay and attrition.
I’ve covered the subject of entropy elsewhere, and why you cannot escape it. The real question is, if disorder is inevitable, why bother?
🤕 For one, it hurts. It slows you down and can directly make the difference between success and failure of your business.
💸 On the other hand, upkeep incurs a cost. This is often not directly quantifiable, but a hidden item in your payroll costs.
The tension between having to keep everything shipshape in order to stay agile, and the real, monetary cost it causes maneuvers many decision makers into a difficult situation. How many developer hours should we allocate to dealing with tech debt? How can we measure how well we are faring? What percentage of our opportunity costs is devoted to maintenance? Where do we even start?
Let me share the good news last: Attractor can help answer many of these questions:
- a transparent scoring system allows you to track your progress as you’re restoring order. You’ll have data available to gauge the development.
- alarm bells ring when a part of your codebase is degrading faster than the others. No more worries about “tech debt creep”.
- analysis tools identify the worst offending modules where repair has the highest impact on the health of your application. No more stabbing in the darkness of code complexity.