The Crumbling Codebase

Julian Rubisch on

An abstract painting of a crumbling fortress made of code in the sunset

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?

  1. ๐Ÿค• For one, it hurts. It slows you down and can directly make the difference between success and failure of your business.

  2. ๐Ÿ’ธ 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:

Boost your development velocity today.

Keep shipping your Ruby and JavaScript apps fast and tackle tech debt before it hurts.