Paying and minimizing technical debt

Paying and minimizing technical debt

Like nearly every software product, Deveo accumulates technical debt. Technical debt accumulates because of various reasons, and typically being in a hurry is somehow always interconnected to the reasons. In this blog post, I will share my insights related to technical debt, and how we minimize it and pay it back.

Different reasons for accumulating technical debt

I have listed below some of the reasons for accumulating technical debt at Deveo. There is a complete list in the appropriate Wikipedia page, but the ones below match to my personal experiences.

  • Business pressures
  • Lack of test suites
  • Lack of documentation and collaboration
  • Parallel development
  • Lack of knowledge

Like any other sane software company, we at Deveo try to proactively minimize the amount of technical debt as well as pay it back continuously. I will cover below some of the techniques we have utilized in order to minimize and pay back technical debt.

Business pressures

Especially in startup context, business pressure can be a prevalent beast, lurking behind every corner. The good thing about business pressures is, however, that as a business representative, you may absorb the pressure, and let the development team focus on its core functionality, and getting most out of themselves. But it's not just about absorbing the pressure. A good business representative knows how to say no, and communicate the pace of development as well as any delays with dignity.

Lack of test suites

Lacking a test suite for a feature, or even larger whole can cause quite awkward moments to your end users. As long as I can remember, Deveo backend has always had a decent test coverage, but after rewriting our web client with Ember.js, for a moment, our front end was without a test suite. This caused multiple situations of regression problems for already "finished" features when new changes were implemented. With even the simplest "happy day scenarios" in place, we were able to pinpoint those problems right when they occurred.

Lack of documentation and collaboration

Deveo is a 100% remote company with employees currently in five different countries. Collaboration and documentation are thus interconnected topics. Sometimes when features require changes to both front end and backend, for example, we have had some ambiguities between developers about how a certain functionality should be implemented. Ensuring that there is a certain level of documentation can greatly reduce the ambiguity between developers and ensure that the right thing gets implemented.

Parallel development

Developing larger functionalities in parallel that are interconnected can cause a lot of pain. We have had two occurrences lately, so called Deveo UI 3.0, and upgrading Ember to 1.13. Deveo UI 3.0 is a refurnishing of our web clients UI to look even better while Ember upgrade is more or less a typical tech upgrade to next major version. Both of the tasks were implemented in parallel with normal feature development, which caused delays and other grief.

Lack of knowledge

Sometimes you find features that are simply out of your expertise or consist of new technologies you have no experience with, and that's the beauty of doing development. In some cases rushing right into implementation can cause, and has caused for us some problems, such as doubling the time it takes to implement a given feature.

Minimizing the debt

We at Deveo try to continuously learn and improve our ways of implementing world class software product. We are by no means perfect, but every small improvement and effort we put on enhancing both how we work, and how our product works, takes us one step further. Below are listed some examples of the things we do in order to avoid accumulating technical debt.

Better specifications

We use issue tracking to track our progress. As Deveo has grown both from the number of customers point of view as well as the number of employees point of view, not everyone can be on the same page regarding everything. Thus having only titles in development tasks is not enough. We started to applying specifications in the form of user stories with very loose rules. This helps us not only to clear ambiguity but improve efficiency in many cases where information is no longer needed to be asked from peers.

Research tasks

For larger functionalities, such as upcoming SAML 2.0 based authentication support or already available multi-site replication functionality, we follow a two-phase process, where a given task is first researched thoroughly, and only then implemented. This helps us to choose the best solutions that are applicable in the long term.

Integrate early and often

For tasks such as the Deveo UI 3.0, we have learned that the things we need to do in parallel should be kept to a minimum. Integrating early and as often as possible avoids conflicts and yields faster release times even for our more complex features.

Paying back the debt

Even though we proactively try to minimize the amount of technical debt, it keeps accumulating. We have tried the following two approaches to pay it back gradually and steadily.

Bug days

We have committed to spend one day a month to fix bugs and smaller annoyances. This practice has been proven to be good for small and easy fixes. It has also allowed us to do minor enhancements that would have otherwise had no priority in our backlog.

A full week specified for bug fixing and small enhancements

We are at the moment trying a new approach, which is spending an entire week, a so-called mini sprint, just for bug fixing and minor enhancements. This has allowed us to tackle some long persisting complex problems that have bothered our end users, and that we weren't able to fix during one day bug days. This is the first time we tried longer time span for enhancements and bug fixes, and at least so far the results are positive. At the time of writing (Tuesday afternoon) we have already shipped 12 new fixes or enhancements. I would say pretty good. Let's see what the numbers look at the end of the week.

Conclusion

I'm more than interested to hear, how have you improved your development organization related to avoiding and paying back technical debt. Share your experiences by commenting below, or share this post forward, if you found it insightful.

Seamless software development.

Code management and collaboration platform with Git, Subversion, and Mercurial.

Sign up for free
comments powered by Disqus