Measuring Technical Debt

Where should a company invest their technology dollars? What should your precious resources be working on? Why can we ever seem to fix what is wrong with our architecture and code to make it easier extend while the various customers keep piling on the new feature request? Etcetera! It is difficult to balance out project work, maintenance work and R&D work. But your organization will not be healthy unless this is balanced. You will have customers that won't trust you when you tell them to release and you will fix the bugs later, because later never seems to come. You will be frustrated because you can't try out new technologies, nor fix what is wrong. What you need to do is create situations for dialog and transparency in the work and the impact of choices. Organizing the effort into portfolios can help shed transparency on IT workload. Your choices lie in one of three basic portfolios: Discovery/Innovation, Project and Asset/Maintenance. The question would be what would be the most appropriate way to measure the value of each of the items in each portfolio to try to strike a balance between the new project and feature work, but also getting around to update software, architectures and fixing bugs. I have been thinking about the first and the later lately and I am going to share a few thoughts about each over a few blog post. Asset/Maintenance portfolio would contain all of your hardware and software licenses and track what is under warranty, what has reached its end of life. This portfolio gives you the means to track and make decisions about upgrades and system purchases. It can also shed light on where you have overlap and lend in consolidating your infrastructure. The problem is that this does not address the custom code that never gets attention from developers because they are trying to satisfy their customers demands for the next great thing. Some code that is written is of high quality, other bits is of lower quality, but how do we make this transparent? Through categorizing it as technical debt. You are doing something cheaper, faster, less knowledgeable now at a greater cost in the future.
I need to collect my thoughts and trials of ways I have dealt with this. That will be a future post.