DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Maintenance
  4. Manage Technical Debt: How to Shine a Light on Issues in Your Code Base

Manage Technical Debt: How to Shine a Light on Issues in Your Code Base

If you've let your technical debt get large, tackling it and making it more manageable can seem like a daunting task. Read on for great tips on how to improve tech debt.

Freyja Spaven user avatar by
Freyja Spaven
·
Mar. 13, 17 · Opinion
Like (3)
Save
Tweet
Share
5.48K Views

Join the DZone community and get the full member experience.

Join For Free

As large software projects creep closer to looming deadlines, pressure to ship on time and under budget forces teams into trying to deliver too much too soon. Inevitably, this results in imperfect code that negatively impacts software quality.

The next set of requirements bounces into view, and before you know it “we’ll fix it later” becomes a company culture that promotes an unhealthy and counterproductive way to build software. 

Bigger projects get added to the schedule, and issues present in production get baked into the layers of code, accumulating into what many teams know as ‘technical debt.’

What technical debt you may see in a project is different to what is actually going on

 

















The thing about technical debt is that we know every large code base has it, but the question is, to what extent? 

Unfortunately, ignorance isn’t bliss.

What Technical Debt Is (And What it Isn’t)

Imagine your desired outcome is a finished two storey house. You build the first floor, but poor planning and time pressure forced a less than ideal start. The foundation wasn’t quite right, and someone wasn’t thorough with tying loose cables! But, the project must go on. The customer changes their mind and wants to build a skyscraper instead. You don’t have time to remove the first floor, so you just continue to build.

The architect doesn’t like the look of things and wanted a 17th century mansion. So what you end up with is an extremely unstable, unsafe - and frankly - scary looking building:

 

good architecture vs bad architecture

 







Like any debt, the technical kind will come back to bite you, and it won’t be pretty. You have to pay it back at some point. You can’t control external requirements but you can choose to architect correctly in response to them, and when to do so.

Technical debt can’t be avoided altogether of course. There’s no perfect system due to the tradeoffs that must be made, and attempting to ship gold-plated code every time isn’t scalable, contributing to delays.

We can however increase visibility on how much technical debt is being accumulated, and from there begin to be more proactive about fixes by improving the processes that lead to the technical debt in the first place. 

Your end users and key stakeholders will thank you for it.

How to Recognise Technical Debt Levels

Because technical debt is a metaphor (albeit a useful one), discovering the causes and fixing them is not an exact science. There’s almost always more technical debt in a project than you think. As developers move from project to project under ever-present deadlines due to market realities, technical debt begins to accumulate.

There's always more technical debt in projects than you think

Team leads don’t spend as much time in the code base as they used to, obscuring their visibility on the health of the company’s applications. Individual developers may be tempted to default to hacks and workarounds to meet their estimates and deadlines.  Tell tale symptoms appear as a result of technical debt in the project:

  • Software bugs.
  • Performance and quality issues.
  • Difficulty extending existing implementations.
  • Estimates not lining up with deliverables.
  • End users complaining and higher support costs.
  • Increased churn rate for SaaS businesses.
  • Staff burnout.

To reduce the likelihood of these negatives occurring, re-evaluating the processes that lead to them is a good first step.

Take a Look at Your Processes

It may pay to consider a tick-tock mentality where a series of feature additions are completed, then a period for software errors/stability/performance is allowed. During this time, refactoring components is essential to ensuring improvements scale, and are integrated and extensible with the larger system.


Allow time in the development cycle for technical debt

Extra time for software errors/stability/performance improvements put your team back in control, so you can choose when to pay back technical debt. After paying back your debt, systems will often gain breathing room and be future-proofed for growth. The code base will be ready for the next round of features and requirements.

Make Improvements

Software bugs and performance issues are simply the inevitable side effects of concerns that come about during the development lifecycle. Therefore the only way for technical leads to recognize tech debt is to accept that you have it – it’s a matter of to what extent.

To get a measure of the extent of the damage, get feedback from the people in the code all day long. Do you find intermediates and seniors mentioning code smells, tricky refactorings, or frequently coming across a sea of edge cases? Are ops awake at 3AM every few days? 

In other words, where are the main pain points for your team? Get them to give estimates for fixing those pain points and front load the work. Start to build a culture of quality first, and provide an environment where your team members feel comfortable bringing up issues that they get a bad feeling about. As visibility into the health of your software improves, it becomes more fulfilling for your development team to write good, solid code. It suddenly becomes fun to take an investigative approach into things like software errors and actually have fun in a problem solving environment. 

Measuring technical debt is like measuring the length of a piece of string – pretty impossible. But now we’ve built a relationship between technical debt and something measurable (like software errors), we’ve added an element of quantifiability – technical debt’s arch nemesis.

How to Provide Benchmarks to Get Your Whole Team on the Same Page

Rushed deadlines, crunch times, and poor tooling are sure fire ways for code quality to suffer. There is a need to present a well structured argument for saying “let’s delay this feature.” Or even “let’s invest in better tools to support our growth,” or “I need more resources to fix bugs and rearchitect.”

So now we know the symptoms of technical debt, we can start to provide benchmarks around improving those symptoms.

What are the symptoms of technical debt?

You can’t measure technical debt, it’s far too vague. But you can measure software errors, performance, and the general health of your software. This will give you a starting point for getting a handle on your technical debt.

Don’t worry about metrics being granular; perfect code is not the aim here. However, don’t forget even small improvements to page load speed will increase the likelihood of someone using your application for longer.

We go into detail about which KPIs you should be measuring for peak software performance in this article. In summary, we hold our leadership team accountable to four major metrics:

  • Users affected by bugs.
  • Median application response time.
  • P99 application response time.
  • Resolved bugs.

Measuring and improving these KPIs will give your end users fast software and result in less software crashes. From here you can start allocating your resources to addressing accumulated technical debt where it’s affecting your business most – at the end user level.

A Note on Visibility

Measuring tech debt is the first step to getting your team in the spirit of consistently creating great code. Making the metrics visible to your entire team will be the final nail in technical debt’s coffin.

Using tools like Raygun's Dashboards feature can bring technical debt to the front of your mind:

Manage technical debt using Raygun's dashboard feature

Stimulate conversation in your team around errors, performance issues, and KPIs. People notice when numbers on a screen improve, and as people talk, you may find your technical debt starts to repay itself, your code base becomes more manageable, and more enjoyable to work with.

The End of Technical Debt?

Not quite. A level of technical debt is an inevitable side product of our fast paced software world.

But don’t let your tech debt remain unquantified! It’s too easy for people to wash their hands of responsibility. Technical debt is everyone’s problem, and once you bring the issues to the surface, fixing them is far easier.

tech debt Software teams Light (web browser)

Published at DZone with permission of Freyja Spaven, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Kotlin Is More Fun Than Java And This Is a Big Deal
  • Microservices Discovery With Eureka
  • 2023 Software Testing Trends: A Look Ahead at the Industry's Future
  • How to Deploy Machine Learning Models on AWS Lambda Using Docker

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: