Technical Debt Warning


Currently, my daily job involves software development in IBM mainframes in the insurance industry but, in my spare time, I’m dedicated to web development as a Ruby and Rails enthusiats. The difference between the methodologies used in the more modern web oriented industry and the old school COBOL environment are huge.Thus, from time to time, I try to bring some of the better, more modern, software development practices to my daily job and as part of the editorial board of my company’s IT Department newsletter, I had the opportunity to include the following article to the last month’s edition. Enjoy!

Technical Debt - Don’t let it accumulate

Software development, just like a house mortgage, incurs a certain debt that needs to be paid frequently and as early as possible, as the cost increases over time and it might end up being too expensive to afford.

Whenever we cut corners on our software development process, we create technical debt, and if we don’t stop to assess what we are delivering—ready to refactor and improve the code—we are setting ourselves up to deliver bad software.

Timed deadlines happen for many reasons: attempt to release a solution before the competition; regulations—legal changes that need to be applied to our product—; the mistaken belief that, the faster we deliver, the cheaper the project is; or any other reasons that force us to deliver within a certain timeframe.

How do we deliver faster? We copy code in many different places, sometimes from other programs that were not properly designed to begin with. We try to use existing programs and subroutines, adding code to an already convoluted program. During the testing phase, we make sure the solution works, but if something fails or a new functionality needs to be added or changed, maintenance becomes a nightmare, and that’s when all the money we thought we were saving needs to be used, and sometimes even more than the savings.

The farther the development goes, the more expensive changes become. Fixing bugs or correcting design errors at the beginning of the project is a lot cheaper than after it goes to production.

We can all agree that attempting to identify all the requirements at the beginning of the development phase may not be ideal. If we are lucky, we might be able to identify most of what needs to be done, but there will always be unexpected changes. Thus, we can say the technical debt is a constant on software development. That validates the saying “The way to deliver the right solution is to start again after you finish.”

The million dollar question is: how can we save money while paying technical debt? The best option: refactoring. Refactoring is rewriting the code to clean it or improve quality without affecting functionality, it might even run faster, but the main idea is to make it easier to understand and easier to maintain.

Refactoring should not be an individual developer’s initiative but part of the process. Time spent on refactoring must be accounted for as part of the estimation and planning process. Automated tests help save money as well as make it possible to quickly identify if anything was broken during the refactoring. If it takes a long time and a lot of effort to retest we could end up with other added costs.

Reviewing code frequently to clean it up is a good habit and should be done frequently, but it takes time so a buy in is needed from project members, most importantly managers and stakeholders.