Worse than technical debt

There is this term “technical debt”, invented by Ward Cunningham apparently. It says that like debt in finances, if we need something now, we can borrow from the future, and then repay it later on, with interest. So we choose fastest solution to production, and then we repay a debt with interest by having our velocity slowed down because the fastest way is not the most maintainable.

Indeed this is sometimes the case, but what I’ve seen is, in most cases, the solution that developers choose to implement is too “fat”. It looks like the opposite of technical debt’s definition — the solution accounts for all possibilities, it is flexible and extensible. So the developers coming to work on that code have no right to say that they are slow because someone previously wrote this crap. And yet, it’s so fat that you cannot avoid it, it imposes some higher level architectural decisions which you must now take into account to interact with that code. The developers were anticipating what’s to come next, and made sure that their solution will be ready for that. They forgot that what’s coming next may never come. And now, when the business goals change, the architectural decisions that they imposed, are not accelerating further development, but impeding it. It’s an amateur code. And because amateurs are better than beginners, their code is harder to work around. They know a few tricks how to make it sure who’s the boss. I don’t know hot to call it, but it’s worse than technical debt. Let’s call it technical speculation — because disregarding the rare case that the requirements are indeed in line with what was anticipated by developer, it will slow you down. It will take more time to develop, and it will slow down further progress even more than technical debt.

Beginners produce technical debt. Amateurs produce technical speculation. Pro’s produce.. well.. reasonable code, I guess…