Facebook EmaiInACirclel
IT strategy

Managing Technical Debt: Balancing Speed and Quality

Cosmin POP

Agile Coach


Special thanks to George Naftanaila and Daniel Radu for sharing great ideas about managing technical debt. Their valuable contribution led to the writing of an important part of this article.

 

Tick-tock, tick-tock … It’s time-to-market! But is your software product ready to compete in a constantly evolving industry? In a competitive market you will often have to implement quick solutions that, unless managed properly, will burden you with technical debt in the long run. When deciding to implement quick workarounds to honor tight deadlines, you have to be aware of the amount of technical debt your actions are generating.

Managing technical debt

If moving fast is your top priority when developing a software product, you will be forced to make decisions that create technical debt. However, unless you want to compromise quality, you will eventually have to spend time and effort into refactoring and cleaning up your code to pay off your debt.

 

Understanding Technical Debt

“The best time to refactor your code and pay your technical debt is yesterday. The 2nd best time is now.”Mario Fusco – Drools Core Developer at Red Hat

Before rushing into any decisions that might cost you time, money and, more importantly, software quality, it is crucial to understand what technical debt actually is.

When faced with a business challenge that necessitates a coding response, development teams have two options. They can take the extra time needed to write scalable and robust code, or they can respond with quick, even messy fixes to address the current problem, but this will require future technical intervention to clean up the code. It is the second choice that generates technical debt, which is a temporary compromise where both the dev team and the client are willing to advance business objectives over software quality.

Technical debt refers to scalability and performance issues that fall under the “fix it later” category:

  • Non-compliance with coding and engineering best practices
  • Code workarounds that lead to duplication, unnecessary complexity or unused components
  • Postponed technology upgrades
  • Bypassed security-related functionality

 

Think beyond “Now”: technical debt is a long-term investment

Why is it so important to limit technical debt? Because it is a long-term investment in software quality: the more technical debt you build up during a project’s lifecycle, the lower the quality of the final product.

Managing technical debt is a team effort that requires forward-thinking. It is about choosing delayed gratification over an immediate result. Developers need to spend time writing quality code from the beginning rather than writing spaghetti code and quick fixes to push something through that they are going to have to spend time untangling later. Though delaying time to market might sound like too high a price to pay, making a long-term investing in software quality by keeping technical debt at a manageable level adds more value to a software project than a series of short-term fixes.

Investing time into coding will result in:

  • Highly scalable code that is easy to maintain
    Well-written code reduces the time spent on maintenance tasks and fixes while also making improvements much easier to implement, even when making changes that alter the initial project specifications. The effort you invest in software quality will be returned tenfold in regards to time and budget.
  • Clean code that allows the fast integration of new team members
    There is no guarantee that a project will be delivered by the initially contracted team. When code is clear and follows the guidelines of the language it has been written in, it becomes easier for newcomers to blend into a team and become productive.
  • Quality code that motivates the team to do better
    Building up a high quality project will increase team morale and loyalty as people are more motivated to build something that actually works, rather than the annoying task of dealing with a never-ending amount of technical debt. Code that requires refactoring every time a new feature needs to be accommodated demotivates the team and increases turnover rate, which entails additional recruitment costs, a decrease in team productivity and extra time spent on integrating new members.

“High-quality software is not expensive. High-quality software is faster and cheaper to build and maintain than low-quality software, from initial development all the way through total cost of ownership.” Capers Jones – VP and Chief Technology Officer at Namcook Analytics.

 

When handling technical debt, think Agile

Being Agile gives development teams an extra edge when managing technical debt. Agile methodologies come with a set of engineering best practices that help teams organize themselves to tackle technical challenges. Agile principles help you perform the balancing act between code quality and fast implementation.

Agile teams can manage technical debt because they:

  • Only accept technical debt after carefully considering its repercussions. Accepting a certain amount of technical debt is viable if it is done strategically.
  • Have a clear Definition of Done that must include the acceptable limit of technical debt and a specific test coverage value. Completing code review sessions before a new software functionality is released helps a team decide whether or not they have achieved the level of quality they defined as acceptable.
  • Use a defined code review process that consists of a checklist agreed upon and used systematically by the team.
  • Measure technical debt either automatically, by integrating code analysis tools such as SonarQube, or manually, by identifying what fixes and implementations need to be postponed and making sure they are all mentioned on a list of technical subjects to be dealt with before next releases are planned.
  • Make technical debt part of the team’s daily job and empower them to take action focused on reducing technical debt during each Sprint.
  • Define a Technical Backlog in parallel with the Product Backlog, which allows the team to set up Sprints dedicated to code stabilization and refactoring.
  • Keep the level of technical debt transparent, all team members and the client are aware of the current technical debt which facilitates decision-making.
  • Think proactively and include technical debt management as part of their continuous improvement strategy.
  • Encourage clients to engage in technical debt management by discussing their vision and business strategy as well as the level of technical debt they are willing to accept.

 

It’s a matter of shared responsibility

It’s not possible to put one person in charge of managing technical debt, keeping it under control, especially in an Agile context, is a responsibility shared between the development team, the Scrum Master, the Product Owner and the client. Everyone has their role to play:

  • The Development Team drives the process
    The developers are the ones writing the code and it is their duty to follow coding standards and software engineering best practices. They should also be expected to systematically review and test their code. Developers always need to think about the future when designing the software architecture and choosing the technology stack in order to build a scalable and flexible solution.
  • The Scrum Master sets the wheels in motion and keeps them running smoothly
    The Scrum Master plays the role of a manager and facilitator, it is his responsibility to measure technical debt and make sure that the Definition of Done is respected by the team. They also foster an environment conducive to collaboration for both the team and the client, which ensures transparency on both sides.
  • The Product Owner navigates
    The Product Owner is responsible for guiding the team. They do this by clearly defining the product vision, explaining the client’s strategy, and by establishing goals and prioritizing them according to their business value. Product owners also provide direction by explaining the impact of technical debt on software quality to clients.
  • The client changes gears
    The client decides how fast the team should move depending on the business growth strategy they want to implement and how disruptive their product is. Some companies are willing to sacrifice code quality to accelerate time-to-market, while others value quality and prefer to advance at a slower pace. However, a client needs to be aware of the effects of technical debt in order to make an informed decision.

“In the end, it’s all a matter of choice: where time to market is essential, the debt might actually be a good investment, but it’s imperative to remain aware of this debt and the increased friction it will impose on the development team.”(Technical Debt: From Metaphor to Theory and Practice, by Philippe Kruchten, Robert L. Nord and Ipek Ozkaya)

 

It’s time to take action

Managing technical debt is a balancing act between quality and time to market. Each business needs to find the balance that works best for them. Sometimes taking on technical debt is the right strategy for a business, though for longer term projects it is often important to take on technical debt gradually, if at all, rather than piling it on, which will make it increasingly harder to maintain and scale the code of your application. Managing technical debt is not just a technical decision but an important business skill.

If you need advice on managing technical debt or setting up an Agile-based project, contact us today. Our consultants are ready to support throughout every step of your product’s lifecycle.

Learn more about the Agile transformation and how Agility and fast ramp up will ensure project success or discover how to ensure that your team will deliver on time.

If you enjoyed this article, read more about the author, Cosmin POP.


Leave a Reply

Your email address will not be published. Required fields are marked *

By using the pages of this website, you agree to our Cookie Use. Read more here

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close