

Technical debt: What it is and why you should care - sirduncan
http://sdtimes.com/technical-debt-care/

======
bengali3
A hot topic for sure, but this is a highly simplified view in my opinion.
(remember too that everyone's experiences vary)

>There are tools that can evaluate your existing software code and determine
estimated levels of technical debt. If your IT department is not using this,
force them to do it. If they can’t, hire someone who can

Tools shouldn't be a requirement, a culture of open dialog should be. Your
team knows where the risks are, make sure they are comfortable raising issues
and are able to prioritize them AS A TEAM.

>Lastly, now that you now about the silent killer, make sure that you adopt
the software development practices necessary to insure that excellent code
quality is baked into the product. Adopt BDD/TDD and Continuous Integration
and Delivery.

For my teams I like to put the CI foundations first instead of last. This lays
the groundwork for TDD. Also understand that the dynamics of changing a team
to BDD/TDD is a much larger undertaking ( with plenty of risks all in its own
right ) and can take months of hard work and time investment.

Setting up CI gets all the delivery roadblocks out in the open and enables the
team to focus on repeat-ability and reliability. A simple accounting exercise
in documenting all the instances of technical debt does nothing to directly
resolve these issues and is a burden in its own right. While sometimes useful,
it should be a living document and part of the teams process, not merely a
one-and-done step.

A wholly separate topic is explaining technical debt to business users who may
not be truly familiar with SDLC.

