Technical Debt in your team

technicaldebtOn twitter recently I read a few people talking about technical debt and how it occurs and how to best tackle it, so here is my view on said subject.

Technical Debt

Technical debt comes in many forms, shapes and sizes and almost every team/developer is aware of technical debt within your company.

Over the years I’ve worked in several companies most of which knew they had a fair bit of technical debt and did very little about it, sometimes nothing, so here are a few examples and how to go about fixing your technical debt:-

We didn’t write it
So the developers who wrote the code have all left, ok then task a couple of current developer to report on this project and ask them to give your team a heads up on the state of the code base and there suggestions for removing this as technical debt, either get people up to speed with the code base, document the current state of the code base and perhaps even find out if its worth re-writing but by all means do something with this technical debt.

Don’t let it mount up over time, It’ll be like the cupboard or the attic in the house where you put all the stuff you don’t want look at and that is not where you want to get to.

If the code is apart of your projects then your team owns that code, no one else does, it’s not an excuse.

The code is written using old technology
Same as above, then document it, offer suggestions to get it up to newer technologies and task people with doing something about it, don’t let it remain in the state it currently is.

The code has no tests
Same as before, get a developer up to speed with it and write unit tests, refactor the code and document they’re findings, it won remain technical debt for very long

I realise that some technical debt there is just nothing you can do, maybe you don’t have the source code for it or you don’t have any developers who know the language well enough to update the application, perhaps no one in your team knows how it’s supposed to work. The thing here is to try your very best to do something with your technical debt and as a team talk about it, work at decreasing the amount of technical debt your team owns, take actions to fix, document, rewrite or whatever but do something about it now, don’t let time drag on and just let it grow.

Don’t start on new features unless they are critical and fix your technical debt, it could make the next persons job a lot easier and that can only be a good thing.

Document your solutions, the number of times I have started looking at code and asked what does this do and no one in the team can answer the question is quite scary, that should never be the case in my opinion.