What is technical debt?
Technical debt (also known as design debt or code debt) is a recent metaphor referring to the eventual consequences of any system design, software architecture or software development within a code base.
Recently I’ve been hearing the phrase used much more often, sometimes it’s setting the scene by a developer before a rushed fix is put into place, or how poor code is explained in a system. I accept this as part of software development but hearing this phrase from non technical people causes me concern.
Is this acceptable? Hearing that it’s OK to incur technical debt to deliver a project early I think not. Debt used to be a word that had respect, folks didn’t want debt but a change in attitude with a pay it back later mentality is something people are more comfortable with in the modern world.
In my experience the intention is always to return and pay it back, but rarely does this happen. The realisation of reducing the ability to deliver change to a customer base isn’t acceptable. But just like any debts the issue compounds until it’s unmanageable.
Working on a code base full of technical debt is uninspiring and saps the life out of all that surround it, and once it’s acceptable to allow the debt more will almost always follow.
Don’t be afraid to re-factor and redesign, sometimes it will punch you in jewels but learn, embrace and improve. Working within an environment that holds these values close breeds a sense of ownership and pride and ultimately promotes good practice to all.
Without debt holding change back, delivery will flourish and accomplishment will bring pride and courage.