3 Outside the Box Ways of Measuring Technical Debtby QArea Team on August 5, 2015
Technical debt is a burdensome and troublesome happening that haunts numerous software development projects. Technical or Code Debt is an approximate estimate of work (coding in our case) that needs to be done before any piece of software under development may be considered complete. Making the long story short, the more Code Debt you have, the longer it will take for you to release your complete app out into the market. This involves investing in development without any ROI or additional earnings. That’s exactly what Code Debt is and why it is bad. Now, that we are clear let’s proceed to our next part of the story.
Code Debt management
You know what they say: can’t beat ‘em – join ‘em! If you cannot avoid Code Debt as it’s the very process of work that is required to be done before release you can manage it and shorten it as much as possible. That is why remaining in control over development is especially important for stakeholders and business owners.
Surely there are numerous practices business undertake to manage throughout development and measure potential size of the technical debt. Cyclomatic Complexity is by far one of best known and used ways as this method is outstanding in terms of software complexity identification. This is a quantitative measure that operates total numbers of independent linear paths that go through any app’s source code.
This method is known and is greed, especially given numbers of additional and individual modules, classes, functions, etc. If Cyclomatic Complexity is used right you will indeed get a more or less clear picture of you code debt and will be able to plan appropriate course of actions. However this method is tricky, burdensome, a bit too manual and hard in use within large-scale projects as involved parties may get confused. However there are alternatives!
Managing code debt is not a one-way road and has numerous spinoffs and practices that may be applied for better results in particular kinds of projects and processes. Let’s look at three alternative ways of managing amounts of required code:
- Cards. Visualization has already proven to be a valid method of workflow management. You can dedicate a particular spot on any wall and stick appropriate cards to it. It should be a kind of place your developers see often. Behind your coffee machine would be perfect if you have but one team working on a single product. Create appropriate code debt story cards and mark them respectively. Try using cards with red, black and yellow to make them 100% obvious. You can even add elements of gamification to this process. Obviously this way of management is perfect for in-house teams and won’t prove to be of great value if your business outsources development. Why this works? Technical debt (as in: DEBT) emerges from tiny bits of cheating here and there. Doing stuff fast and dirty does lead to poor results and when developers see where they went wrong they will most likely stop their malicious activities.
- Sonar. It has a special plugin for our purposes. Not only does it analyze the process and delivers results but it is entirely created with respect to maintaining appropriate flow of development. Let’s face it, adding functionality without appropriately testing it (unit testing, integration testing regression testing, etc.) is a blind shot that may work in theory, yet in practice brings demise and destruction. Sonar will assist with arranging projects appropriately and is best used in Continuous Integration or Continuous Delivery development environments.
- SLOC. This metric is also quite well known and is surprisingly simple in terms of code debt analysis. SLOC stands for Source Lines of Code and is approximately equal to technical debt. More lines of code equal more technical debt. As easy as that. Considering duplication is one of the largest reasons code debt exists SLOC is a handy metric. Repeating lines of code lead to unnecessary duplications of algorithms and even core concepts. That’s why analyzing actual size of your code can help you a lot.
However you may find something even more appropriate for your product under development and its code debt analysis we highly recommend maintaining development clean, simple and continuous. Such an approach will leave you with a lot less trouble to worry about.
Check out our related articles: