Reducing Technical Debt

Technical debt in Software Development is not something new. Every software has some technical debt and no software is perfect. While building an application,web, mobile, desktop, there is a plan, a strategy, analysis, development and after all is set and done, if well planned, this application should be able to satisfy completely 80% of it’s users while the remaining 20% will be asking for a feature that probably would take 80% of a sprint time to be developed.

Software Engineering is in part a response to a business need. When there is a business need there is also the need of a deliverable and usually those dates aren’t defined by the engineering team and this leads to technical debt.

In order to successfully reduce technical debt is important that there is a clear understanding from business and engineering what is technical debt. In software development technical debt can be simply put as a “bug”.

A bug, a good nickname with some historical background, is in fact a flaw in the application and as any other flaw it has its level.

Critical → Stops business or completely halts the application. In web application is a good old friend of the developer as http status code 500.

High → Won't stop business but it will cause damage on data or application experience that can’t be restored.

Medium → Doesn’t stop neither business or the application but annoy bringing a large number of customer service calls.

Irrelevant → Causes no harm neither to business or the application but should be fixed eventually.

When you look at this levels, even without being a software engineer, it is known that the Irrelevant bugs will always be pushed to the backburner accumulating time over time until it becomes relevant growing up a level. Medium and High are usually scheduled and properly tested in a release cycle, being removed from the technical debt queue as soon as they are set to resolved. Criticals, well, they must be fixed as soon as they are informed, this means that the whole development is set to a halt so the defect can be fixed immediately.

What most of the corporations don’t pay attention to is why bugs and defects appear during the engineering of the application. Most of the times there are simple reasons why they happen and very simple strategies of how to avoid them.

Bugs can be originated by:

  • Lack of understanding of the feature → Every software engineer have seen this before. A feature request with just one line expressing: “Just do like the other one was done.”. What it is not seen is that the developer responsible for that feature doesn’t necessarily knows what was done before and even if it is the same developer, chances are, that the feature was requested a long time ago and by now he/she doesn’t remember it anymore. The bottom line on this origin is that business requires to give enough details to develop a feature correctly and whenever these aren’t available, the developer is required to ask for them.
  • Lack of experience for developing the feature or to fix a bug → Every developer has a skill level. Some developers are more experienced in one area of the code than others and even when, there is rotation, this should be supervised closely. If a developer does not have enough skill set to develop a complicated feature or doesn’t know enough of the given source of the code to fix a given bug he might generate a bug while developing.
  • Lack of sufficient time to ensure quality of the feature → It is true. Time is money. The more time, the better right? Yes! but that also reflects in another direction, time is quality. Like the prior sources there are strategies to ensure enough time for a feature to be done correctly.
  • Stress on the professional developing the feature → If a football player gets injured he won't be able to play. Developers aren’t, by profession, sportsmans but they use in a daily basis their brain and their fingers to write software code. A stressed professional won’t be able to think correctly and therefore he/she will generate bugs.
  • Cutting corners → This one is my personal favorite. I love when a solution to a feature is done by being clever or there is no required completeness of a feature because time was low and there was a decision to make it “so so”. This is so dangerous that I have only one way to express how critical bugs can come out of this. Imagine if you are flying on a plane that someone was tapping the engine for this flight? Don’t believe this could happen? Search Google images for Cutting Corners and you will see it.
  • Sindrome of the broken pipe → Patching an application that is already broken will only break it more.

It is not even necessary to say that every problem has a solution, and if there is no believe in that then start loving math.

Technical debt can be reduced and, in some cases, extinct and to make that possible there are strategies that actually doesn’t require a single of code.

The following strategies will help diminish right away the technical debt and not only improve quality of the software but also quality of the communication among business and developers.

  • When facing a critical bug that will require an immediate production deployment, do not assign to a developer, assign it to a technical task team. A technical task team must be composed of one or more Software Engineer, a dedicated QA Analyst, a team member responsible to communicate with business to gather information about the issue and to inform about the progress of the development, a team member, experienced enough, to do the code review and finally a DevOps to ensure deployment. The important on this strategy is that everyone knows their role and that the amount of time required to deliver the solution is already short because is a critical issue in production. The team must be focused and must know how to communicate well with each other in order to deliver the best quality solution in the minimum time possible.
  • Every release should have time dedicated to reduce the technical debt and all bugs scheduled for the release have priority over features.
  • Avoid at all cost interruption on the developers. There are studies done that proves that a single minute that a developer is interrupted will required him / her about 30 minutes to be focused back on the task that was being done. Focus is by far the most important resource of a developer while working on a task. A developer out of focus, either by an interruption or by stress is in fact losing one of the most important tools to develop and deliver the task.
  • Listen to your developer when he / she says “I need more time”. It is important to find out why the extra time is being requested and, if there is a reasonable situation that would require more time, that time must be provided. It is a simple matter of quality.
  • Code reviews: I’m a software engineer and like many, I wasn’t particularly happy when someone reviewed my code, but with experience I came to learn that it is an important thing. A code review is not supposed to point fingers on what is wrong but to explain and suggest why something might generate an issue and how a certain area of the code can be improved. A non judged code review can alone improve the application quality.
  • A sprint dedicated to free will development. Every developer has a pet peeve on the code that, after that it was delivered, would like to change. Small refactors, rewrites, new features. There is a lot that can be gained on sprints where the developers decide in what they will be working on. By experience I can affirm that most of the time it will be some form of refactor for code improvement.
  • Keep your development team current with the tools and technologies that they use to develop the features. It is very important that education of a developer doesn’t stop. Think about it as a game. Every conference that a developer attend, every meetup that a developer goes to, he / she will have the skill set leveled up.
  • Use a standard. Coding standards, same development tools, same resources. The more is invested in the quality of development the less bugs will be generated.

The strategies above will help reduce the technical debt and improve code quality but there are some tools, that requires some code writing that will enforce quality and can prevent a bug to even leave the development cycle.

  • Automated testing → Doesn’t matter the tool used. Automated testing is by far the best method to perform regression testing.
  • Unit testing → Is an excellent way to prevent that a block of code (or a unit of code) returns a result different from what is expected.
  • Front end testing → Similar to Unit Testing but for the front facing of the application (Behat for example).

All these tools and strategies will not prevent a bug to happen, but it will diminish the possibility of it happening. Applying these strategies on a development shop that is currently with a high level of technical debt is hard, but not impossible and if you need a reason to justify it, make it simple. The more time you fix bugs the less will be the time for you to code a feature. The end result of this is a final product that can’t be improved and that is costly to maintain generating the need of a full rewrite or generating a high rotation of Engineering team.

Like what you read? Give Cristiano D. Silva a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.