Learn more about Velocity Partners offshore software development company

 

 

This is a continuation of an article on Refactoring and Technical Debt. In part one we set the stage for it. Now I want to delver into some strategies for handling refactoring and reducing your technical debt. As in everything, it isn’t easy nor free, but it is worth the effort.

Strategies

I have used a set of strategies quite effectively to combat technical debt and inspire refactoring in several companies. There is no succinct “silver bullet”. However, if you apply the following with persistence, you will be well on your way to delivering more sound and robust products.

Stop Digging the Hole Any Deeper

Almost a no-brainer initial strategy is to “stop making your debt worse”!  This involves all new functionality. For every story that you develop, you want to ensure that you do not make your technical debt any worse. So, the initial story is very relevant here. You want to hold the line on new work and make sure you are “doing things right”.

While I was coaching at iContact, a trigger word in our team discussions was “hack”. Whenever a team member spoke about “hacking something together”, we knew that it would be creating technical debt and need later refactoring. So we worked incredibly hard to avoid “hacks”.

Fill in the Hole

Once you show the discipline to hold the line on new work, you can then go back and start refactoring legacy crud that has developed over time. This usually is a longer-term strategy in many organizations and requires great persistence. It is also a moving target to some degree, so patience is needed as well.

I like to engage the team in identifying refactoring targets. Avoid the “we have to fix everything” syndrome and ask the team for the highest priority refactoring targets by way of value – for example, removing impediments to the development team’s efficiency or capacity.

Broadly Attack Refactoring

Balance is a key in refactoring. Attack technical debt in all its forms and do not necessarily focus on one component or type of debt. You want to look at your entire codebase, tool-base, script-base, documentation-base, etc. in your retrospectives and select high-impact, high-return refactoring opportunities. Then apply a bit of relentlessness in pursuing and improving those areas.

Make the Business Case

Even though I talk about refactoring being an organizational and team responsibility, it does not get supported by magic. Teams need to identify (document) their refactoring work on their Product Backlogs. The business case for each improvement needs to be explored or explained, particularly if you are going to get your Product Owner to support you.

So yes, it is a responsibility. But you need to put the rationale and the ROI in clear business terms. Then “connect the dots” back to the ROI after you have refactored the code, perhaps discussing or showing improved implementation speed in a Sprint Review.

Talk About the COST

Remember that refactoring often has a cost in time-to-market. Bugs take longer to fix or cluster in ways that influence customer confidence and usability. Maintainability is a strong factor in being truly nimble and creative. At iContact we often selected and justified our refactoring targets by how they would support our future product roadmap and support faster implementation times.

Then, when we had completed the refactoring, we would look back on those improvement estimates and speak to the reality of the improvements – connecting the dots, if you will.

Don’t Attack Too Much at Once

One of the hardest things to do in many organizations, those with debt-rich legacy systems, is to prioritize the technical debt. There is so much and it is causing so much harm, that the inclination is to try and fix it all at once. But nothing could be more detrimental from a business perspective. As you would handle anything on your backlog, prioritize it and systematically attack it.

Invest in Test Automation

I have often heard the notion that a value proposition of building solid test automation is that it provides a “safety net” so that the team can courageously refactor. The point is that if there is little to no test automation, teams are reluctant-to-fearful to refactor because of side effects and how hard it is to detect (test for) them. I have found this to be incredibly true.

So a part of any refactoring effort should be focused on building test automation coverage. The two efforts strategically go hand-in-hand.

Find Release Tempo Opportunities

Most agile teams today have multiple tempos: sprint tempo, release or release train tempo, and calendar or external release tempo. You want to think about your various tempos and perhaps find opportunities within them for a focus on technical debt and refactoring. For example:

Many SaaS product companies have downtime periods in the calendar year when they do not necessarily want to release new code to their clients. At iContact, our time was over the Christmas holidays. From November to December each year we needed to keep releases to a minimum while our customers focused on holiday revenue. Given that, we would plan “Refactoring Sprints & Releases” over that period. Sometimes we focused on product code, for example broad-brush defect repairs and component or feature refactoring. Another season we worked on our continuous deployment capabilities – focusing on scripting, tools, and deployment automation.

It was a great way for us to make investments and not disrupt our Product Roadmap plans.

Make it an Ongoing Investment

And the final strategic point is making it clear to everyone that technical debt and refactoring are an ongoing challenge and investment. They will not “go away”. Even if you are implementing a greenfield project, you will be surprised how quickly you gain refactoring debt. It is driven by the nature of software – the customer needs change, technologies evolve and change, and teams change. In other words, change happens, so simply factor it into your strategic plans, roadmaps, and ongoing product backlogs.

Wrapping Up

The sub-title for this article was: it’s not a choice, it’s a responsibility. I hope the introductory story helped to crystalize that point. But I would like to emphasize it even more now.

Stakeholders will rarely tell you where and when to refactor. In fact, they typically hate the notion of refactoring, infrastructural investment, ongoing maintenance, etc.  Instead they usually push their teams towards more and more new features. This pressure is organizational and will seep into the product organization, each Product Owner, and their teams. However, just because we are under pressure, it does not mean we need to abdicate our responsibilities and blindly succumb to it.

Rather, we need to activate our craftsmanship, our professionalism, our responsibility for doing good work and our courage to deliver that work. In other words, delivering software that will stand the test of time, that will exceed our customers’ expectations, and that we can be proud of. All of that might sound trite or too simplistic, but it is a core part of the principles behind the Agile methods.

And, beyond simply words, each agile team and organization needs to make its technical debt (risks) and its refactoring efforts (investments) transparent. They need to become part of the everyday discussion that teams, managers, and senior leaders have as they transform their organizations towards agile execution. Striking a transparent balance should be the goal. And I strongly suspect that everyone’s “common sense and gut feelings” will let him or her know when they have achieved it.

As always, thanks for listening,

Bob.

References

1. Technical debt definition –
2. Managing Software Debt by Chris Sterling is a wonderful book dedicated to all aspects of technical software debt.
3. Here’s a link to an article/whitepaper I wrote on Technical Test Debt – a variant of technical debt that focuses on the testing and automation aspects –
4. A recent perspective by Henrik Kniberg –
5. A fairly solid overview of technical debt with some solid references –
6. Israel Gat of the Cutter Consortium has published several papers with his views on measuring and the ROI of Technical Debt. Searching for his works would be a good investment.