
Saying “technical debt” is lazy - sdoowpilihp
https://medium.com/@sdoowpilihp/saying-technical-debt-is-lazy-5b42d936408c#.2gj9x12ld
======
angersock
"Technical debt" as a catch-all is not ideal, but it's usually an easier sell
than "We need to start looking at and fixing the never-ending procession of
short-sighted and slipshod decisions that you, management, and you, lazy
developers, have apparently booked for a year-round appearance in our
codebase."

The problem is that "technical debt" has no bearing on the business
functioning of any company whose primary deliverable is not a piece of
technology. At best, it's seen as a sort of odd thing that suddenly causes
schedules to slip and engineers to quit; at worst, it's dismissed out-of-hand
and ignored.

There is really no good way of explaining to non-software-engineers why
technical debt is a big deal in such a way that they prioritize it as
something to be addressed. The article's suggestion that you break it down
into actionable items fails: technical debt can't be explained in terms of any
individual issue, because the problem isn't any particular issue--and if you
try to do it that way, each issue invites a hacky solution that drives you
further into debt!

It's a _culture_ , it's _craftsmanship_ , it's _ownership_ , and it's
_quality_ that are attacked by technical debt. It's how you guarantee that
only malicious geniuses and shitty developers stay on your project.

