We know technical debt is bad. As Rick Garvin wrote in Headwinds: Legacy Technology’s Invisible Drag, it “can reduce your company’s velocity, productivity and agility.” But how can you deal with it? The Ten Mile Square approach is to make it part of your design and planning activities. Arm yourself with the information about your company’s technical assets, take ownership of those assets, and develop a plan to deal with obsolescent technology. This is the path to smashing technical debt.
Take Inventory
Before you act, you need to know what you have, but just trying to get a handle on your technology inventory can be daunting if you haven’t performed this exercise in a while. We find this to be especially true for organizations, regardless of size, that are more focused on getting something out the door than worrying about the impact of technical debt. But it doesn’t have to be difficult, and often you’ll find that it’s a matter of starting with the data your tools already provide. Here are some you might already have in your environment that will help make discovery easier:
- Configuration Management tools, such as Ansible and Chef, can be a great way to pull information about your technical assets. They can also be used to poll against IaaS/PaaS CLIs to perform auto-discovery.
- Bug tracking or centralized logging tools can identify unique applications, services, operating systems and hardware.
- Network discovery and monitoring tools can identify networked devices based on open ports, OS fingerprinting (TTL window size and other techniques). Depending upon network security, however, you might find that these tools will not yield a complete view.
- For larger organizations, IT Service Management (ITSM) and Configuration Management Database (CMDB) tools such as ServiceNow have the information needed, as long as it’s been validated and up-to-date.
If none of these are available, it is time to do some archaeology. Start with interviewing the business owners and the technology teams who build and support the systems. This will at least get you an inventory of the major hardware and software. This may not be 100% complete, but it is better than pretending technical debt doesn’t exist.
Also, check to see if you’re running multiple versions of the same system or have multiple systems doing the same thing. This would be a great opportunity to do some Marie Kondo on your software and tidy it up.
Take Ownership
Once you know what you have, ensure that there are responsible parties assigned to each asset. If an asset is lacking an owner, assign one. This is critical because without an owner the assets will atrophy and become increasingly difficult to use. If you’ve experienced ‘shared services’ tools without an owner, you know what I mean. A typical example is a tool like Jenkins, the software development automation package. Without ownership to care and manage it, it won’t be long before jobs take forever to run and no one feels authorized to make a change.
Develop a Plan
Smashing technical debt has to be planned and aligned with the business goals. In addition to the information you’ve gathered so far, you will need additional data points such as:
- Business criticality of the asset
- Costs (licenses, support, total cost of ownership, depreciation, amortization)
- Dependencies / relationships
- Regulatory requirements
- Security requirements
Again, we’re going for a good enough set of data points, not a detailed analysis that will take months to complete. Remember, this is an activity you’ll do frequently, so you should find new ways to keep your inventory up-to-date.
Because you will likely not have the budget or time to do everything, this information will allow you to prioritize the needed work. From that prioritized list of tasks, you can build a plan.
Smash Technical Debt!
Now comes the fun part. Implementation will need to be coordinated with the users, both the business and tech teams, to ensure a smooth transition. Some common approaches to smashing technical debt include:
- Bam Bam — Just smash the technical debt, pull the plug….well maybe just take it offline to see if there are any other users or assets that you didn’t know were using that system. This assumes you have done your due diligence and know that no one is using the asset or you have received no responses to your queries. Have a plan in place in case you do get a response after you smash it.
- Wait Until the Hood Is Open — Wait to address the technical debt until the system or component is next touched in the due course of work.
- Retire in Place — Adjust your business practices and other systems such that the system is no longer used and just let it die a natural death. This only works, of course, if you’re not actually spending money to keep it running.
Boom. Technical debt smashed….or at least curated and managed.
Iterate
Smashing technical debt is never done. While the tech stack might not change, the people, partners, and companies do. Repeat this cycle as needed.
A word of caution, keeping technical debt in check requires diligence. It’s not an exercise you perform once and think you have rid of yourself of it forever. When you’re planning new systems, account for the effort needed to keep it up to date and eventually retire it. This needs to be documented in your roadmap. From a strategic perspective, this should be reviewed annually at a minimum. From a tactical perspective, it should be reviewed during any upfront application or system design, backlog grooming, or similar activity.
Ten Mile Square Can Help
We can help you address your technical debt by:
- Assessing the scope of your technical debt, technology process gaps, and team gaps.
- Prioritizing the technical debt remediation in line with your features backlog,
- Providing technology leadership, process remediation and team coaching.
- Applying hands-on technology modernization, infrastructure update and software development.
More Resources:
- By Frank Oelschlager
- by Ward Cunningham
- by Martin Fowler
- by Steve McConnell