Kim Arnett Technical debt is a natural part of software development. New frameworks come out, better ways to do things are found, SDK and languages updates are a thing, plus a hundred other external influences in your project. All of these things lead to old code that needs to be updated to keep on par with the new code your team is writing. If there's not a process to incorporate some of these updates and maintenance, it leads to an outstanding technical debt.
What is Technical Debt?
Technical debt is a backlog of tasks, code, documentation, frameworks or other "things" that need attention, and the level of effort it would take to clear out those to-do items.
Why Should You Care About Technical Debt?
As software developers, we all enjoy consistency within the project and cleanliness in our code. We don't enjoy referencing things we'll never get to, //TODO: marks, or //HACK: marks, or outdated comments. There's n number of things that could be applied here, but these are some examples of the most common I see. Anyway - if you're not addressing debt as apart of your process, it grows. It grows quickly, and before you know it - it's a large effort to make a simple change. Addressing technical debt keeps your project clean, team mates happier, and maintains the most updated information you have at that time.
Ok, Where Do I Go From Here?
The first step in tackling anything is defining scope. Talk to your team about what bothers them in the project. There are tools like Sonar that can get you started as well, identifying areas with low test coverage or duplicated functions. This step will vary team to team. I personally like identifying unused files, duplicated functions or functionality, and areas with messy logic where a bug is likely hiding.
Once scope is defined, the next step is plan of attack. This will vary from team to team. If you need buy-in from the requirement side of your job, have those conversations early and often. Pulling 1-2 stories in your sprint to start should be an easy goal without much implications to the requirement goals. Remember, this isn't just a nice to have, cleaner, consistent code is more likely to be bug free, tested, and easier to maintain in the long run. A few hours now will save hundred of hours in the future.
Attack! As you're knocking out stories, whether outside of the sprint as you can or apart of the sprint, document any other problem areas you find that could use a touch up. Add tests to anything you do if they don't exist, and if they do, yay! With existing tests, you'll have confidence that your refactor update didn't break anything. Which is why it's important to add them if they don't exist!
Maintenance - going forward follow the above steps to ensure you and your team are staying on top of any technical debt that arises. The beautiful thing about end of the year slow downs around holiday time is that there's often lack of features being built due to code freezes and everyone being on vacation. This is the perfect opportunity to make sure your code is in good shape for the new year!
That's it! Go on and make your projects beautiful and less stressful for future you. Report back on how it's going. :)
