Technical Debt - Part 2: Identification
Join the DZone community and get the full member experience.Join For Free
we discussed the process of defining technical debt in a previous article which outlines some important items that should be considered before going about identifying it within an organization. only after a clear vision of what technical debt means to the organization has been established should one go about the process of trying to find it. some sources of debt are going to be easier to find than others. unfortunately, the most difficult sources to find sometimes present the most risk. the process of identifying technical debt should be evolutionary where each iteration of the process incorporates feedback from the previous iteration.
sometimes just looking at how a project team communicates provides clues that technical debt may exist. in a talk by andy lester , he provides a list of signs that can indicate the existence of debt. if you hear a project team make any of the following statements it can be cause for concern.
· don’t we have documentation on the file layouts?
· i thought we had a test for that!
· if i change x it is going to break y….i think.
· don’t touch that code. the last time we did it took weeks to fix.
· the server is down. where are the backups?
· where is the email about that bug?
· we can’t upgrade. no one understands the code.
while a lot of technical folks will get a good laugh when reading that list of statements, they are laughing because they’ve likely heard each of them several times. each statement points to a potential source of technical debt such as insufficient documentation, inadequate qa processes, a code base in need of refactoring, the lack of a disaster recovery plan and the absence of a formal bug tracking system. these statements also indicate sources of interest that is being paid such as drains on productivity, reworking broken code, inability to migrate to current platforms and potentially lost data.
unfortunately it isn’t always possible to tap into team communications to look for suspicious language. however, it is often possible to define measures to help zero in on where debt may exist. these measures can be both qualitative and quantitative and act as leading and lagging indicators of the inevitable interest payments. these metrics do offer the possibility of creating technical debt kris (key risk indicators). these kris could then be assembled into dashboards and/or heat maps to highlight potential areas of concern. let’s take a look at a few examples.
|kri:||poor code quality|
|reason:||poor code quality is probably the number one source of technical debt. its existence can slow down new development and maintenance to the point of paralysis.|
|metrics:||uncommented, complicated and duplicated code|
|source:||there are a number of automated tools available which can generate code quality metrics automatically. ndepend is a good example.|
|kri:||inadequate code coverage|
|reason:||the percentage of code that has automated tests associated with is usually inversely proportional to the number of defects that make their way to the end user. you’re usually not aiming for 100% coverage but the higher the risk the higher the code coverage should be.|
|metrics:||percent code coverage|
|source:||there are a number of automated tools available which can generate code coverage metrics automatically. ncover is a good example.|
|reason:||when applications are not compliant with standards defined by the organization a variety of challenges arise including data loss, system failure and inability to support new technologies.|
|metrics:||number of systems using unapproved technologies, number of unpatched servers, age of disaster recover tests|
|source:||utilities exist for testing for unpatched servers but reporting mechanisms might need to be adopted to generate other metrics.|
|reason:||the inability to meet service level agreements can be a good indicator that teams are contending with ineffective architecture or poorly implemented code.|
|metrics:||enhancement request aging, frequency/length of outages|
|source:||monitoring tools exist to report on outages but reporting mechanisms will likely need to be put in place to provide visibility to request aging.|
|reason:||as systems and processes are evaluated by both internal and external auditors, they are examined for gaps and deficiencies that represent technical debt.|
|metrics:||number of “needs improvement” and “unsatisfactory” it audits|
|source:||reporting mechanisms will likely need to be put in place to provide visibility to audit results.|
|kri:||poor data quality|
|reason:||a large percentage of data quality issues are the result of gaps in transformation processes and front/back end validation controls.|
|metrics:||number of data quality defects|
|source:||automated tools exist which allow the creation of data integrity rules and provide consolidated reporting. informatica data quality is a good example.|
as the size of the organization and breadth of the search for debt grows larger, so do the challenges. in larger organizations, broad initiatives that identify issues and implicate individuals will meet resistance. no one likes to be told that their group or department is not meeting expectations. larger initiatives need to be championed by the senior leaders of the organization to head off pushback. additionally, when technical debt is discovered it needs to be handled with care. if managers are punished or looked upon unfavorably it will create friction that could short circuit the entire process.
managers should be encouraged to self-identify technical debt and be rewarded for doing so by having the remediation prioritized appropriately. the carrot works better than the stick in these situations because there are always ways to fudge metrics. having proper code coverage is only useful if effective tests are written to evaluate the code. if developers write ineffective tests just to keep their metrics green quality will suffer. if managers are rewarded with the resources necessary to make their teams more efficient there will be an incentive to make the process work. conversely, if they are punished they will try to game the system and avoid the negative consequences.
there are a number of potential challenges associated with identifying technical debt. these challenges grow exponentially if the wrong approach is used. as we discussed, the right approach involves an evolutionary approach to identification and making sure that there are incentives for getting technical debt on the corporate radar. there are also a number of frameworks available (e.g. cobit, itil, pmbok, etc) to help identify potential gaps and outline best it practices. making the management of technical debt part of the corporate culture is the key to long term success. consider establishing a central repository to track it, use project management tools that facilitate that tracking, and creating an awareness initiative on why managing technical debt is in everyone’s best interest.
Opinions expressed by DZone contributors are their own.