1

My team (yet) did not do much to work on technical debt and our code base includes huge amount of TODO code, unused code, 'could get better' code, @Ignore unitests and more.

I am about to start dealing with those issues, and as we work on production product and have many other things to do, i was thinking of this strategy:

  1. One engineer will be assigned for 0.5-1x day every week to deal with technical debt, he will only work this day/half day on maintaining code. As we have more than 4x developers in team (6x developers) this can be once a month (and more) for each developer.

  2. We will use apps (plugins) such as SonarLint (https://www.sonarlint.org/), CheckStyle and IntelliJ inspection to inspect our codebase.

  3. Each engineer will have to fill a checklist of it 'technical-debt-fight' as we will work module by module :: 'remove unused code' checkbox, 'finish 1x todo' checkbox, ....etc

  4. Summary will be filled after each day (in a few words, like a commit summary) so the other engineer who keeps his work the week after will be able to do this.

  5. Once a month-two we will review work / speak about this process and set timing for it ending (half a year process?)

As this can be monotonic/sometimes boring/unpleasant work, I find using checklists and 'forcing' team a good idea. As I would myself be happy to look on a checklist and see what needs to get done. Especially as this is once-a-month work.

What do you think of this plan? how would you do 'attack' this technical debt issue?

Besides that i'm planning to read more about Martin Fowler refactoring notes.

Any other recommendations are welcome! Thanks!

Improve this question
3
  • 1
    It often takes more than a single day to make your way through the SDLC. How do you plan on handling it when someone’s clean up bleeds into a second day? Commented Nov 21, 2018 at 17:38
  • 1
    TODO comments and 'could get better code' can become issues on your backlog. The issues can estimated and assigned to sprints as needed. You can remove the TODO and 'improve this' comments from the source code, since they add little. This might be far less work than doing all TODOs and improving everything the original programmers thought needed improving during technical dept cleanup sessions. And project management can decide what to fix first and what crappy code to keep as is. Commented Nov 21, 2018 at 19:19
  • 1
    Thanks, this will not be a perfect solution (if it takes more than a single day), but it's a start. Maybe if one finds a fix that might last for more days - it will stay in his mind to fix the todo when his time frees. I can't give more than 1-2x days as product is more important atm Commented Nov 22, 2018 at 7:56

3 Answers 3

Reset to default
4

I wouldn’t specifically start refactoring random things you’re otherwise not working on unless they are EXTREMELY bad. Ignored tests may be such a case if it means the functionality they’re testing is broken.

Rather, I would apply the philosophy of leaving the code in a better state than you found it, whenever you have to touch it. This is much easier to sell to the business side of the company, even though implementing features may initially take a little bit longer. It also greatly reduces the ‘oopsies’ where you introduce a new bug during refactoring while not quite into the functionality you were touching.

Of course, if code is plain unused, just throw it away. You have version control for that.

As a side note, I would recommend not using TODO’s in code unless you plan to do it IN the branch you’re working on. Either do it straight away or use an issue tracker or something similar for remaining changes.

This also touches the fact that you shouldn’t compromise on quality too often. There occasionally are valid business scenarios for it, but in the end you as a developer are responsible for good code. The push from the business side to do things faster will literally ALWAYS be there, but if that means you’re regularly writing poor quality and/or untested code, that is your own responsibility.

Improve this answer
1
  • 1
    It's also much cheaper to fix code near other code you are working on anyway, as you don't have to re-familiarize yourself with the code's context. Slow and steady improvements that foster a culture of quality are likely to work much better then always cutting corners in the hope of fixing the TODOs later. Commented Nov 22, 2018 at 14:46
3

Refactoring efforts should be defined, planned and worked on as regular issues, not regarded as one big blob of technical dept that is expected to vanish over time as a result of some time slices having been reserved for it. Take it seriously, define what your problems are and treat it as work. It is work.

Improve this answer
1
  • hey- thanks, we are not suitable (yet) for full refactoring efforts, but i'm thinking of the idea that if developers will be 'forced' to do those days- the 'spirit' of writing better code will be more out there. and in the long run the effect will get us to write better code. plus- the code base will get better than it is right now. what do you think? Commented Nov 22, 2018 at 16:29
2

In my experience of reducing technical debt, you will need to ensure you have good code coverage. It's difficult (and dull) to do this in one go or even if you set aside time to do this. Usually the engineer will get a task to fix an issue or implement a new feature.

Fix an issue

  1. Write tests where it passes under the current (buggy) scenario.
  2. Write tests that fails, i.e. it will pass after fixing the bug.
  3. Do the least amount of work to get test 1 to fail and test 2 to pass. No need to do anything fancy here, we just want the correct tests to pass.
  4. Delete the first test which should now be failing.
  5. Now it's safe to refactor the code since there are tests that are backing the business logic. SOLID principles will help here.
  6. Now you can refactor the tests too.

Implement new code

  1. In some cases the engineer will need to first write passing tests around the code that will be affected by the new feature.
  2. Write failing tests for the new feature, which will pass later after implementing the new feature.
  3. Do the least amount of work to get the tests to pass.
  4. Now refactor the code. SOLID principles will help here.
  5. Now refactor the tests too.

Code will look perfect when it's first implemented. Later on (maybe in a months time) it won't look so pretty. If there are already suitable tests, then it's easy and safe to refactor the code to suite the new code environment. This is an important step in keeping on top of technical debt.

The refactoring notes by Martin Fowler are a very good starting point.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.