Mar 10, 2022How to Get Your Technical Debt Under Control
Unless you live in la-la land with a dream team of developers who
write perfect code, it is impossible to avoid technical debt. It is a
natural by-product of fast-paced development of any SaaS product.
As
developers, we always have to choose between delivering on time and
delivering with perfect code. It's a trade-off. In most cases, we choose
to deliver on time, with a promise to deal with the byproduct later.
Technical debt also occurs because of reasons such as: Change in technology Development of annual frameworks and libraries Non-maintenance of codebase or libraries Introduction of new product features Addition of a new workforce to an existing project to ship faster Need for frequent releases and pressure of timeline
And
so, technical debt accumulates. We can either ignore it until it
snowballs into something massive or fix some of it to reduce its impact
on current and future development.
I have seen teams try to
figure out everything from the beginning so there is no minimum tech
debt. But in an environment where delivery time matters, slowing down
development could cause companies to lose opportunities or customers to
competitors.
It makes more sense to come to peace with the
fact that there will always be some technical debt. Acknowledging this
and then defining some best practices to manage technical debt
effectively can reduce its impact on your product. 10 Ways to Manage Your Technical Debt 1. Opt for Modular and Extensible Architecture
An excellent way to start a new project is by adopting an extensible architecture.
This involves accounting for all our current requirements while
extending the project to add new features in the future without any
rewriting.
Start with identifying the various modules based
on their functionalities. Develop each module so it is independent and
does not affect the working of other modules. However, all the modules
should be loosely coupled. By doing this, you can easily break the
project into multiple microservices and scale them individually if the
need arises. 2. Develop Only What is Required
To
build a product or its modules with more flexibility (or to make the
next release easy), developers may load it with extra functionalities.
This is only effective if you are sure about the future requirements,
which is never the case. These added functionalities build up over time,
increasing your technical debt. 3. Plan Your Trade-Offs Carefully
Pick
what matters the most. For long-term projects that have a high return
on investment, carefully consider the design and implementation and
minimize technical debt as much as possible. If delivery is the top
priority and efforts to build are low, you can knowingly create some
debt you can fix later. 4. Never send POC to production
Before
developing a new feature or a product, developers build a proof of
concept (POC) to check its feasibility or to convey the idea. If the POC
is accepted, the feature is included in the road map.
At times, especially when it is working as expected, it is very tempting to put this POC into production.
However,
that is a bad idea. A POC is just what it says: a concept, not a
complete solution. While developing a POC, we rarely think of all use
cases or scenarios because the focus is on writing the code to get
desired results quickly. That code is never meant for production, and
writing tests around it usually doesn't work. Most of the time, POCs
don’t have proper structures, error handling, data validation or
extensibility. Use it as a reference and only deploy a complete
production solution. 5. Write Code With Proper Documentation
Good
code with proper documentation offers multiple benefits, including
quick handoff to others, increased reusability and reduced time to build
more on top of your code.
There are two types of documentation: within your code and about your code. Both are equally important.
Some examples of documentation within your code are: Function signature Instructions for users Descriptions explaining confusing or complex pieces of code To-dos for future reconsideration Notes for yourself Comments about recent changes
Examples of documentation about your code include: Readme files APIs reference How-to guides FAQs 6. Request Early Code Freezes
Frequent
releases (often with limited resources) are major contributors to the
accumulation of technical debt. To meet tight deadlines, developers add
hard-coded values or resort to quick fixes in codes. And there are
always last-minute requirements or requests for change in
functionalities. Over time, these quick fixes lead to performance,
stability and functional issues.
A good way to deal with
this is to introduce a process for early code freeze, so developers can
focus on improving code quality and stability instead of adding code
until the last minute. 7. Add Technical Debt in Sprint
Eliminating
technical debt all at once is not feasible. Product managers are not
likely to commit extensive resources since it adds no direct or
immediate value to customers. At the same time, developers want to spend
more time developing something concrete, from scratch, instead of
reworking on the same code.
But there is a practical way
out: Create a healthy backlog of debt items and a road map (with
timeline) to replace the code's hard-coded, unoptimized and quick-fix
scenarios. Add stories to every sprint so you can fix these debt items
gradually and in a more organized way. 8. Version Your Code
Your
code will likely change as you add new features to your application.
One of the best ways to track and maintain these changes is to version
your code.
You can create incremental code through
versioning, leave behind some old code, introduce breaking changes
through newer versions, give users access to multiple versions and stop
support for older versions. All of this is in your control.
Versioning
is probably the best process through which your code evolves. It is
also the preferred way in the SaaS world to shape (or reshape) your
product over time without piling up a lot of baggage from the legacy
code. 9. Refactoring is Your Friend
Refactoring is
the ultimate weapon in your fight against tech debt. How often you need
to refactor the code is up to you, but doing this regularly is
essential. Make sure you version your changes while refactoring. This
keeps your code organized. 10. Balance is Key
Technical
debt is okay as long as it's intentional and strategic and not the
result of poor codes and design. As developers, our aim should always be
to balance it and cushion its blow to the product.