OverviewPlease read the previous post on improving code-quality using LCOM4 and Cyclomatic Complexity before reading this entry. Below I present two ways of thinking about technical debt in your organizations. The first is the old-school approach, and the second is the approach preferred once the vast amount of cyber-fraud was detected.
Old way of thinking
Before cyber-security became a large concern, software development companies thought differently than now about their approach to their applications. In those days, if you'd run Sonar against your codebase, and identified some areas where your source-code was butt-hurt and you wanted to fix it, you had a problem. See, the viewpoint was that acknowledging flaws in your code was also acknowledging legal liability. So, companies would fix bugs in "maintenance releases" but would not acknowledge the specific security failures they were fixing. This environment of subtlety safeguarded application developers, but exposed end-users to the prospects of security holes as a result of bugs.
Currently, there are massive cyber attacks against companies around the world making companies more appreciative of an increased level of due diligence with their applications. The mark of a successful company is not that they pretend problems don't exist in their code, it is in the fact they acknowledge it, fix it, and communicate it. To understand how to plan to include technical debt resolution, you must first understand the Bucket Parable.
The Bucket Parable.. a digression (bear with me, it pertains)
Back in the olden-days, there was a small village that had a very unique annual contest: the rocks-in-a-bucket contest. The goal was to see who among the competitors could get the most rocks in their buckets. Now, their buckets were all the same size;so, the only thing that differed was the size of the rocks. In the first year's contest, a strong man named "Hugo" won the prize because he had managed to stuff 2 massive rocks into his bucket. The next year, a strapping gentleman on a horse won with 3 rocks, each weighing five pounds each. And the third year? Well, the next legendary player was Mike Van himself, and he was able to stuff over 400 rocks into his bucket. But how, you say? Well, while all the other folks were worrying about the big rocks, Mike Van paid attention to the little rocks too. So, whenever there was a gap between the big rocks, Mike Van filled them with the little rocks. As he began to build up his bucket, he noticed that the massive number of little rocks also gave the bucket extra weight, making it more formidable. Well, Mike Van was proclaimed the winner, after which he went into retirement from rocks-in-a-bucket, moving into a cave to knit "delicates" for poodles. He apparently feels it is a growth investment zone.
The Bucket Parable and Scheduling Technical Debt
If you've ever been on a good development team, you know about feast and famine. There are times that you have so much work to do there you have to work stupid long hours, and there are other times when you play Call of Duty with your co-worker cuz there aint squat. It is this time that the Bucket Parable comes into play.
If you are delivering product, meaning software, on a schedule, that means you have a specific period of time to deliver a specific set of functionality. Think of your timeline as the bucket in the bucket parable. Now, each of your major tasks are going to take up some of the time of one-or-more of your developers. These major tasks are your big rocks. However, what will they do when they're complete?
After you've completed your Sonar analysis and have noted the weaker areas in your codebase, you should create tasks for each item to fix. Then,. in your tracking tool, allow your developers to choose those "little rocks" they can do when/while they do their big rocks. At the end of the development cycle, not only have you completed all of the intended features, you've also completed a large set of smaller tasks including paying down your technical debt. Customers like this. Its good. Do it, then drink beer with friends.