What is Technical Debt?
First of all, you might ask yourself, what is technical debt and why is reducing it important? Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing a limited, often easy solution over a more durable and complex approach that would take longer or have higher costs.
It is not always easy to clearly show a client how spending their time and money to keep technical debt down benefits them. New features, functions, and designs are obvious, but structure and other items that are not visible to anyone outside of the development team are also important and come into play later in the life cycle of the application. Left unchecked, it can end up costing more and adding development time when future features are needed.
A house building analogy makes it more clear - if you have a house and want to add on a new story or a double garage, you have to make sure the foundations are sufficient to support the new load and haven’t been eaten by termites. You must know that your wiring and services meet current standards or you may run into trouble when adding your new garage. From the outside, your house looks no different, but taking care of what you have means you have a firm and solid base you can build upon. Software is just the same.
So when developing new features, a developer should perform routine maintenance to keep an application up-to-date and functioning well. This includes writing tests to ensure new features don’t break existing features, updating the framework to the latest version, or ensuring security updates are done, etc.
For example, keeping an app’s Rails version updated doesn’t bring a direct benefit to the business model, but updates often address security issues, which can prevent the awkward event of being hacked or even a lawsuit because data isn’t kept secure. After all, if you’ve been negligent in updating your software against known or published issues, you are vulnerable and ultimately responsible for any data loss.
Just like financial debt, if left for longer periods of time, technical debt will accumulate ‘interest’ making it harder (more expensive in time and money) to implement mandatory changes. Feature development becomes increasingly difficult or even impossible. And the codebase can become a mine-field of undocumented errors, held together with twine.
It’s important to remember, when building an application, that smart development includes ensuring adequate resources are allocated to write sufficient tests, perform software version updates, performance checks, refactoring and the like. All in addition to new feature development. If not, it might create further issues with the maintainability of your application and increase the technical debt. While a small technical debt might be tolerable, letting it grow can make your application malfunction in the future and cause the loss of precious data and/or customers. I have seen it happen all too frequently.
Here at reinteractive, we aim to maintain an equilibrium between features and maintenance, to ensure no project accrues crippling technical debt. Our standard process is to fully test the features as they are implemented and refactor when necessary. The continuity of this process ensures the project’s maintainability and stability, avoiding dead ends and expensive full code rewrites (an unfortunate by-product of other processes).
Even so, sometimes accruing technical debt is inevitable. For example, the Ruby language we’re using keeps evolving. New versions are released and it’s not always possible, or financially viable, to upgrade right away without major overheads or restructuring.
Other examples that come to mind, are existing applications. Sometimes clients come to us with older applications, where the technical debt hasn’t been paid for years. Older software versions which now have security vulnerabilities, have a lack of adequate test coverage and similar issues can be a challenge for further feature development. Of course, most of these clients are coming to us with new feature requirements as the priority. Paying the technical debt doesn’t rank high on their list. While we may focus on implementing the features, we advise them not to forget about their application maintenance. Keeping an application healthy is crucial for success.
Specifically with Ruby on Rails, with every new version comes performance improvements and time-saving feature updates that improve development speed. Time invested now in upgrading Ruby and Rails versions will ultimately decrease development resources needed for future feature development.
Handling Technical Debt:
To properly address technical debt, it’s crucial to first understand the amount of debt in your application. Tools like brakeman or bundler-audit can give a quick overview of security vulnerabilities in your Ruby version, Rails versions and your gems.
Running skylight.io on your rails application can give insights into controllers or database queries that are breaking or taking an abnormally long time to run. Codeclimate is one of many tools that can give good insights into your test coverage and overall code quality.
These tools (and there are many others) allow you to get an understanding of your technical debt. Knowing and fully understanding the problem is the first step to resolving it. You can most definitely do the work yourself to understand the state of your application code, but if you need a second set of eyes on it, we offer all of the above and a complete report on what we find in our Ruby on Rails Application Review Service.
A good approach to resolving technical debt comes from devoting a set amount of hours every week or month to updating your application. Like setting aside every Friday afternoon to patch any vulnerabilities, increase your test coverage or upgrade versions. At reinteractive, we created our CodeCare to accommodate teams that don’t have the in-house resources to carry out this maintenance. It includes monthly scheduled hours to apply all security updates and to optimising the application or carry out updates and feature requests for our clients.
You are better off knowing and understanding what technical debt lies in your application and addressing it before you find it’s gotten out of hand. And in the worst case scenario where it has gone rampant, requiring a re-write of the entire application codebase.
