Developers Alone Cannot Reduce Technical Debt in a Silo

DZone 's Guide to

Developers Alone Cannot Reduce Technical Debt in a Silo

This article describes how other groups/individual roles in the organization should come together to reduce technical debt.

· Agile Zone ·
Free Resource

Technical Debt is something that accumulates over a period and at some point, it could render an application unviable to maintain. It is like a time bomb which if not diffused soon could cause serious customer repercussions and financial damages to an organization.

With the name ‘technical’ debt, it is often perceived that reducing technical debt is the sole responsibility of the developers. Of course, developers play a key role in refactoring code and reducing technical debt. But refactoring is not always restricted to only the code. Many other groups have to play their related roles to enable refactoring and reduction of technical debt.

You may also like: An Agile Team's Guide to Breaking Down Information Silos

This article describes how other groups/individual roles in the organization should come together to reduce technical debt.

IT Leadership

In the true spirit of one of the Agile principles – ‘Continuous attention to technical excellence’ – the IT leadership should recognize that the ‘perfect’ or ‘great’ solution today may not be able to meet future demands in terms of speed or reliability and may fail to meet customer expectations if it is not continuously reviewed and improved. 

They should understand the value of spending time to make the application robust in the long run. They should allow time and funds to refactor existing code to make it better. They should empower their middle layers and technical SMEs to make the necessary decisions to refactor and improve the existing applications.

Product Owner

The Product Owner (PO) plays a key role in stacking up work for the development team. They do this by gathering business requirements and prioritizing them. The primary consideration of the PO for such prioritization is business value; however, the PO should recognize that the application will continue to perform as expected and provide business value only it is built on strong foundations. 

When the IT team reviews the existing architecture and code and identifies improvement opportunities they will have to accommodate the refactoring effort along with that required to complete the requirements prioritized by the PO. At appropriate intervals, the PO should allow the team to spend time refactoring. This may call for de-prioritizing certain business requirements. But the PO should manage that and take the business stakeholders into confidence.

Business Stakeholders

Along with the Product Owner, the business stakeholders play their role in shaping up a robust application. When it comes to meeting immediate business requirements versus making the application stronger, in the long run, the business stakeholders should make a call at the appropriate time – say a ‘lean’ period – and should be willing to slow down a bit and allow the refactoring effort. They should understand that the time and money spent on refactoring may not show a visible change in the functionality but will help improve the quality and performance of the application. They should also realize that is not good to build functionality over the known inefficiencies of the application.


While refactoring the code the developer could identify improvements in the architecture of the application. The architects should recognize the need for refactoring the architecture and be willing to invest the effort to analyze the impact of the change and refactor the architecture suitably. 

While doing that they should make sure to align with the enterprise architecture. At the same time if they find opportunities to improve the enterprise architecture they should provide such inputs to the enterprise architect community. If this calls for significant changes then the PO and the business stakeholders have to be updated with the implications of the change.

Test Engineers

Every code change will have to be tested before it is deployed to production. Based on the refactored code or design the test engineers – both manual and automated – should be willing to refactor the test cases. There could be multiple possibilities here: some test cases may be redundant and no longer required; some test cases may have to be updated or new test cases may be required to test the new path the code may take after refactoring. While implementing these changes the test engineers should make sure that they do not miss out on validating the original functionality.

It is to be noted that the context here is changes in test cases/script resulting from code refactoring. Reviewing and cleaning up the regression test suite is an exclusive effort under test case/test scrip refactoring.

Infrastructure Team

Sometimes refactoring could identify simpler ways to deploy the application. In such cases, the benefits of refactoring may not be realized in full unless the application is deployed differently. The Infrastructure team should work closely with the developers, architects, and test engineers to identify such changes and provide appropriate environments to test and deploy the refactored code. 

If an organization is matured in DevOps practices this collaboration will be engrained in their ways of working; however, if they are in their early stages of DevOps adoption the leadership of Dev and Ops organizations should enable collaboration to reap the benefits of the refactoring effort.

Technical debt is a broad term that encompasses all the stages of the solution development cycle. It is not limited only to code. The IT and Business stakeholders should take an end-to-end view and refactor the application periodically to reduce technical debt.

Further Reading

Technical Debt Will Kill Your Agile Dreams

The Importance of Keeping on Top of Technical Debt

What Technical Debt Is and How to Calculate It

agile ,devops ,devops and agile ,information silo ,silo ,technical debt

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}