View source for Managing Software Technical Debt

Ways to determine
* Complexity / Class Usage can be used to determine where to look (bug hunting missions)
* Fuck metric, the more the number of fucks to a comment, the more serious the problem
* Source code analysis, manually (peer review) and automatically (tools like code climate)
* Annotate the code, for example https://code.google.com/p/gag/
* http://www.techdebt.org

Discussion of technical debt talked about different debts
* Hacks you were asked for
* Hacks you did to get things done

Gource is one way to analyse code.

There are also tools like Code Climate.

There was a mention of Rich Hickey's talk/presentation "Simple Made Easy": http://www.infoq.com/presentations/Simple-Made-Easy


We discussed the fact that Technical Debt, while it's something that developers know all about and experience sometimes quite tangibly, it is often not visible to the business or product owner and, the conversation focussed on how to make it more visible. 

What followed was then a discussion looking at various tools from ticket management systems, some alternatives like http://www.techdebt.org which are mentioned above, through to using something like a whiteboard with the basic system architecture which is annotated with post-its showing where there are/were code smells, bugs, critical problems, upgrades required. Something like a Technical Debt Heatmap.