Most Technical Debt Is Just Bullshit

Technical debt is only a symptom of the larger forces affecting a code base.

Brian Foote's "Big Ball of Mud" really hits the nail on the head regarding how accumulating technical debt over time can be considered a degenerate architecture:

http://www.laputan.org/mud/mud.html

"A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated.

The overall structure of the system may never have been well defined.

If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems."

>cover up bad code >cover up unfinished work

Absolutely this! I think the question that needs to be asked when you have the excuse of time pressure (or another excuse) is "well, if you had no time pressure, how would you have done it different?"

If they, or you if you are asking yourself this, is "I don't know" then it's not technical debit. It's bullshit. It's just bad code.

So much of "technical debt" I see in the codebases I have to work with has nothing to do with time constraints / deadlines / having to get a feature out ASAP, it's just bad code written by bad developers.

This needs called out more.