All of us are familiar with debt and the challenges that come with it, but it may surprise you to learn that many Chief Information Officers are not familiar with a very real and growing problem and the serious consequences it poses to their companies:

Technical Debt.

It can cause project failure, resignations, firings, employee disengagement and potential business failure. The culprits are not always who you think, but it is undeniably a leadership responsibility.

So how do you know if your company has Technical Debt? Here are a few symptoms: 

“What do you mean it’s going to take 2 months to make that change?… It seems like such a simple thing!…”

“My IT department is always putting out fires. No new development seems to happen…”

“We have so many systems and none of them seem to talk to each other…”

“We can’t seem to keep good developers here very long…”

ACCRUING TECHNICAL DEBT 

1) Deadlines and Other Original Sins
When developers are forced to meet impulse deadlines that don’t reconcile to good metrics, quality suffers. The familiar pattern is to ram code in and fix it later. The trouble is that this type of code is rarely fixed because the software is now working, the deadline has been met and the ramming forgotten during a project completion round of drinks.

The impetus to “fix it later” disappears rapidly. New projects start queuing up and spending time replacing the "coat-hangers and chewing gum code" seems like an unjustifiable waste of time to management. When deadlines are met – bad decisions are forgotten. Let’s just live with it now that it’s in production. Just deal with it…

Developers who warn that this choice leads to less maintainable code in the long run are often given blank stares or labeled complainers by decision makers. This is not a message leadership wants to hear since the option to do it correctly the first time has now passed.

2) The Golf Course and Lobbyists
Software decisions made for relationship-sake, or those pushed down from a CEO to pacify the Sales staff, create ugly integration compromises. These expedient decisions become a permanent legacy for conducting business even when the protagonists are long departed.

While IT was never consulted, they are forced to assume this technical debt and act as historian, librarian and janitor to recount those decisions to future CEOs and other new staff.

3) Compounding Interest
Badly written software that has become part of everyday company life must now be handled with kid gloves. Soon, much of your future software must now comply with that original sin just to maintain operations and that building upon shaky foundations becomes permanently institutionalized in your IT culture.

There is pain involved to developers, users and the company in changing bad code. The pain of writing on top of bad code is often less than reversing that bad decision. As a result, bad code spreads by dependency and your inability to maintain good code hygiene creates generation after generation after generation of pain.

4) Invisibility Cloaks and IT Magic
The biggest cause of lowered developer productivity is Technical Debt.

Technical Debt exists in every line of code and every application. Because it’s in the code, it’s simply not visible to leadership. Developers mostly do a terrible job of explaining this concept because it sounds like whining techno-babble.

Leadership experiences the phenomenon but never directly like a developer or an end-user – they experience it as company inertia. By the time it reaches leadership, most of the harm has already been done.

Technical Debt factors solidly into a negative perception of IT and actively helps to erode client confidence.

5) Keepers of the Code
The world used to be a much simpler place for developers 20+ years ago. Imagine learning history 300+ years ago… not as much to know – text books would have been thinner. Things moved at a slower rate but in 2011 technology moves so quickly it’s the equivalent to jumping aboard a moving train.

As languages evolve, older code becomes increasingly difficult to maintain. Conflicts also arise when companies want to keep the investment in their original applications while developers want to remain current with their skills. Companies who don’t modernize their code base lose good developers, keep bad ones, and continue to increase their technical debt.

Are there bad developers? Sure – just as there are bad recruiters and sales people. The analogies and repercussions are somewhat similar, with one important difference:

Code outlives individuals. You can’t fire code; it is kept by companies and inherited by successive developers.

When developers get aboard the "quick-over-correct" train, Technical Debt is accumulated. This debt is invisible to leadership while that individual remains as an employee and is often only ever exposed once that employee leaves. Much of this is a factor of how they haven't been trained.

While technologies and languages change, there are principles to development – to making code clean and maintainable – that don’t change that much. This is where IT leadership has an increasingly important role and why your ultimate decision on who to work with, and understanding how they work, is critical to the short-and-long-term health of your company's IT infrastructure.