Is technical debt a recurring problem you face, or is trying to future proof the software you write the best course of action? Today, we take a look at one of the most complex problems when creating software, analyzing the pros and cons of both approaches.
by Scio Team
Software development is… complex. At its core, it’s an interesting challenge where improvement and evolution happen alongside the construction of the software itself, with the possibility that it changes course when you learn new things, get a new perspective, or bring diverse points of view to the table.
As we said elsewhere, developing software is very similar to writing a novel, or painting a picture: it’s as much of a discipline as is a creative exercise, borrowing and modifying itself throughout the project. However, there’s a big difference between a book and software; the software is part of an infrastructure, meant to interact with a user, across an undefined period, which gives this profession a unique challenge: what happens to the code I’m writing today when tomorrow arrives?
A debt to ourselves
“It’s OK to borrow against the future, as long as you pay it off”, are the words of Ward Cunningham, one of the authors of the Agile Manifesto, which revolutionized the way we look at software development. We all know how borrowing money works in our daily life, but what he referred to is a specific concept many in the software industry are aware of: Technical Debt.
As you may know, technical debt is “the implied cost of future refactoring or rework to improve the quality of an asset to make it easy to maintain and extend”; is the knowledge that certain parts of a program may require to be fixed at some point in the future.
There are plenty of reasons why a dev team may incur this “debt” (be it for budgeting, skill, or deadline reasons), but the nature of its payment is stumbling onto issues that need to be fixed quickly, which may bring more issues later that will require further fixes and so on, effectively like trying to pay a loan with a high-interest rate. If you are not careful, you will end up paying it perpetually.
Technical Debt is considered a serious problem and plenty of literature and management advice have been written to mitigate its effects, but like with any kind of loan, it can bring plenty of benefits if chosen and managed correctly. After all, if we take on a debt, it is for something in exchange, be it having cash on hand to accomplish something, or achieving working software to solve the issue at hand.
And the proper way to deal with debt, be it technical or otherwise, is to pay it on time, which in software development means refactoring a lot of the work done.
However, depending on the level of debt accrued by a team, this refactoring may bring a hefty tag, especially if the time between creating the program and improving it allowed many dependencies to flourish, or some of the knowledge behind the construction to get lost (such as the original team changing), so you may want to avoid the need of refactoring as much as possible because you don’t know the context in which the program will be improved. So what then?
A proof of thinking ahead
Futureproofing may be the answer. What futureproofing tries to do is “anticipate and minimize the effects of shocks and stresses due to future events.” This practice is not limited to software, but it can help to try and mitigate some of the problems technical debt will bring, especially if we are thinking ahead of the need for refactoring at a certain point in the future or having to deal with legacy software inside critical systems in any organization.
However, saying it is much easier than doing it, and any approach to futureproofing a system, so it can be tinkered with or without issue decades from now, is a tenuous art at best. After all, how can anyone predict what software will look like in 2050? The solutions we implement may make sense today, but will probably need some explanations later.
A solution could be, to create software that follows a pattern, so its logic can be easily deduced by a future dev team, as well as taking the proper due diligence when choosing tools and frameworks that have a better chance to remain supported or at least accessible in the coming years, or avoiding “monoliths” where a single application is responsible for tons of functions, but one can still get blindsided by a development impossible to foresee.
This brings an interesting conundrum for many developers trying to find the right approach: is it better to futureproof software to try and avoid technical debt, or is better to acquire some debt if that means having the flexibility to refactor software at some point in the next few years?
Two sides of the same coin
The reason is very simple, yet has lots of implications: if you acquire technical debt, you cannot futureproof because you are assuming you will need to change things. If you futureproof it, then you are making stuff that will greatly resist refactoring, making it likely to turn into “legacy” software.
A good approach to finding a solution to this is developing products with a few things in mind, mainly no software product is forever, and everything has a shelf life that we will need to wrestle with at some point.
“Generally, it is not until something breaks when a team realizes they have a big debt needing to be paid”, commented Scio’s PMO, Adolfo Cruz, about this issue. “It’s more common when a product is brand new and it’s still building its user base. The volume of transactions is low at first, so you may not see any problems, but if the scalability wasn’t planned well, then it’s more likely that debt will flow under the radar until it’s too late, so it’s important to take steps to prevent this.”
The trick is trying to push back that point as much as possible, having the proper procedures to ensure the code can be fixed. A good commenting discipline, for example, can save a lot of headaches while refactoring an application, letting whoever has to modify it knows what can break and what depends on every function. This can work as futureproofing without going into a lot of technical debt, as many of the problems when trying to refactor old programs is the fact that the code sometimes is not very clear, and in places of a lot of personnel turnover (like a government agency), it’s easy to let cracks grow.
The useful approach, then, is considering both of these concepts as the two sides of the same coin: the delicate balance that is developing good software amidst the needs of the now and the later. A great software development team should strive for products that pass the test of time, while also knowing that nothing is perfect, and using the need for refactoring as a tool, not only a problem.
What do you consider is the best approach when creating software? An application with some debt that will let you fix it in the future if it needs to, or building something hard to repair that may stand the test of time?