Technical Debt and Collateral Damage

for the record, i still don’t like the technical debt metaphor ; i feel that it encourages taking on the debt. we don’t know what will happen, so it makes sense to do things now, even badly, and forget the price we’ll need to pay.

metaphors aside, the price we pay is real. it cannot be quantified easily, but it is there.

this is where you start paying

let’s think about it this way. if we examine our path of development until we have a “good product” (your definition may vary), then the road is already winding like a path in a garden maze. we don’t know if what we build works, if the technology is right, or even if there’s a customer.

so, it’s never a direct line. we take turns, stumble a bit. but let’s assume we’ve done it. that’s the shortest route possible. ideal time.

now, let’s add repaying the technical debt into the equation. think of our maze structure. they’ve grown without trimming, they block our way, they block our view, and there are no signs telling us where to go.

so, our road becomes longer, with a lot more stumbling around. now, the first impact (and maybe the most important) is that the time to market is obviously longer. we do all kind of hacks, we shave yaks, we try to understand why the system works like it does, imagine how not to break it, and wonder who the hell wrote it like that.

while being late, and sometimes not even getting there (or getting there in a different route, which may not be optimal) is bad enough, more things can happen on the way too.

for example, as the project gets longer, things have more chance to change in the market, in the team, in our company, etc. maybe people are fed up with maintaining a crappy code base and leave. maybe a new technology arrives, and we decide to throw everything we’ve done and replace it. or, other projects seem more attractive than ours. not to mention when a wild competing product appears.

even if we are repaying the debt, the complexity of things can derail our projects just because we don’t get there faster.

(then again, things don’t have to go bad; they can also go our way. maybe we didn’t invest in clean code, and it’s easy to throw that code away. maybe killing the project is the best decision we can make. we can only know about it in hindsight. it may be that we have invested in clean code, in features that the customer doesn’t use.)

the idea behind keeping the code and architecture clean and having automation in place is about getting to market in the shortest way possible because we’ve already done the work. if the journey is longer, a lot of things can happen.

that’s why you don’t want to get into debt in the first place.