Author
Cecilia Gutierrez
– Do you think you’ll be able to finish this feature within this sprint?
How many times have you ever been asked this question? And how many times have you developed things not as efficient and well designed as you would have preferred to? I bet many times.
The problem
Technical debt is a daily reality in software development. It arises directly from the agility required by constant requirement changes and incoming deadlines, typical characteristics of agile methodologies applied to the IT industry.
More often than not, we have to deliver work for which we do not have all the details we need to do so. It’s very common to come across unexpected obstacles when developing software, and when the deadline arrives, in most cases, it’s preferred to ship code that’s working -despite how well it was done- rather than nothing.
These above-mentioned issues are particularly important in large-scale projects, where there is a team of several developers working together, and not everybody is familiar with the code. In those cases, code understandability and extensibility are key. Quick and complex architectural decisions may be under your control -at least for a while- if you are working alone, but when your teammates are also going to work with it, it’s not so trivial, or at least it shouldn’t be.
Small improvements are frequently delayed, and after a long time postponing them, the amount of pending architectural improvements keeps getting bigger, and it may end up becoming a huge unmanageable snowball of poorly written code. That’s how it turns into the popular and feared “legacy code” that nobody dares to change. At some point, we’ll come to a dead-end and the only viable solution will be migrating the code to a new repository, usually to new cutting-edge technology.
So, how do we manage it?
There’re plenty of approaches to identify and mitigate technical debt. Most of them are inspired by extreme programming (XP) best practices, such as following coding standards, having short cycles, and incremental design. All of them point to efficient, maintainable, and extensible code.
Here at Moove It each project has different processes depending on its needs and what the client and team agree is more suitable. In some cases, technical debt is addressed and planned within each sprint, sometimes under a specific percentage of the planned hours.
In a particular project, we’re using the following: a 3-week sprint, where the last week is exclusively dedicated to tech debt. Isn’t it fantastic? Which developer wouldn’t like to have a full week at the end of each sprint entirely dedicated to embracing product high-quality and maintainability?
Quality over quantity is one of our key main values. We do our best to apply it across all the aspects of our services, and code is just one of them. When developing a feature, we’re constantly analyzing and looking for diverse alternatives, each with its pros and cons, so that when we come across a tech debt disjunctive, we proceed to create a new task to document this pending work. That way we ensure we don’t forget that something could have been done better, and it actually is done as soon as possible! We have a specific board to organize all these tasks separately from the ones assigned to the current sprint.
Also, each member of the team is encouraged to suggest improvements whenever possible, and we consider every idea equally. Everyone has a valid voice that deserves to be heard on our team.
Conclusion
Technical debt is inevitable in all projects. The key is to figure out which is the best way for the team to handle it according to the project, and of course, the client. Teams should discuss and try different approaches if necessary until finding the most suitable solution, without trying to forcefully adapt themselves to a structured popular process.
There’s no magic recipe, just different approaches for achieving the same objective: have the code as simple and elegant as our process and deadlines allow us.
With all that being said, we invite you to re-think your process in case you’re not dedicating time for embracing code quality. Give it a try! You’ll notice the difference, and coding will be more enjoyable, for sure.
How do you manage technical debt? We would love to hear!
