Several months ago I joined the new for me project team. They have been working on this product for more than a year. You know what it means for the mobile project – we have a tons of code created) So, one of the most severe issues guys mentioned is the crappy code – developers told me that during the first retrospective we had. My first reaction was – “So why do you create this crappy code?”. But the answer was very easy for them – “We inherited that code from the previous team, they created all this awful things!”.
This team is lucky to say that it is not their fault, but other teams I worked with we not so lucky. They worked on the project from scratch. But still they had this problem with the tech debt – you work fast, add new features, but from sprint 7-8 you notice, that velocity drops a bit… If you do nothing – it drops more and more.
Step 1. Identify the problem.
If you hear that the code is crap while drinking coffee at the kitchen or passing by the developer’s table – it’s a bit late. At this moment everyone already knows that project code is a crap and they probably don’t feel very enthusiastic about fixing it.
PM has a great tool – retrospectives – to find out about the problem. You can ask your team to measure the health of the code today. If the health is under certain level – it’s time to act.
When you know that there is a problem – you have the chance to fix it.
Step 2. Identify the reason.
The first thing you team should comfort with – it is they who create the crappy code. It does not appear by itself. So, crappy code exists because developers created it.
Why? Don’t think they are sitting and thinking how to make the code crappy. I think there are two most probable reasons:
- It is how it works – when you create something, you probably have the mess around you. If you are creating a sculpture – you start with the block of stone and cut it, leaving a rock parts around you. You don’t clean immediately – you continue working and don’t pay attention to all that mess. But when you are done – you clean your room. But if you are not – the room will be soon covered with the dust and pieces of rock, so you won’t be able to continue with the next masterpiece. I think it is close to what happens during the development – you have some “working place mess”. The problem rises when you forget to clean your working space – debt is growing and growing.
- “No time” problem – developers are pushed to add new features, they are under a great pressure. PO pushes you to implement new user stories, release is coming, you make “one small quick fix. will improve it later!”. Have you ever returned to the “//TODO change it later” parts? Don’t think so) Usually we leave it as it is. And the debt is growing…
Step 3: Act
Tech debt is not influencing in the short term period, it is a long term horizon problem. You won’t notice any changes this week or in 4 weeks.
PM, it’s you job to make the team say ok to one simple rule – STOP WRITING JUNK CODE. Just stop it 🙂
What if you don’t:
It is the most simple decision. Just close your eyes and don;t think about the problem. But some day(not so far away in the future) you will find yourself asking your team “Why this minor change takes so long????”. Your speed will definitely be influenced by the big tech debt.
What if you do:
Of course, we will have tech debt. But if you keep it under the curtain level – your velocity won’t suffer from it.
To work on the tech debt you definitely spend some additional time. But investing the time in the short term perspective you save time in the long term perspective – much more time than you spent on fixing the debt.
What can help:
- TDD. Keep your test’s green. Add the “Tests created” rule in the “Ready for development” column (or add one more column) to your board.
- Definition of done – don’t allow to set “done” until developer “cleans up” the working space. “Code is good enough” – add this rule to the definition of done on your board.
- You inherited crappy code from your descendants: It is not possible to “overwrite everything” as your team advices you. Just start with reducing the tech debt – when the developer implements the new feature he should clean up the area, connected to the feature – refactor it. It is a small step, but if all the team makes it consistently – the results become visible in a weeks/months.
Step 4: Everything is ok now? It’s time to monitor)
How to monitor the state of the code? It is very difficult to measure the tech debt. So, here we will use a lot of the personal feelings of the development team.
- Add the subcolumn “Tech debt” to your board. When the developer some across the part which need to be refactored, but he has no time to work on it now – he should add that to the “Tech debt” column as the task. Also team should add some improvements, ideas on the clean up to this column. During the sprint – reserve some amount of time for this column tasks. The visualization of the tasks on the board will help you to control the amount of the debt and finally start improving it.
- Check the “Code health” rate during the daily meeting/retrospective. Just ask the developers – they know more than you can imagine. Put that information on your board, so everyone can see. When the level of the “health” is beneath some level – act! We have :), :|, 😦 and ;( for showing the code “health”.
@tisquirrel 