Code quality is a strange thing. It seems to have a high priority before a project starts but often gets totally abandoned once the crunch time of the project begins. In this article I want to illustrate why everyone including managers, product owners, scrum masters and of course developers should care about code quality and give some useful arguments to those developers feeling that their efforts to keep it up are not acknowledged.
Why Should I Care…
…as a Developer
When I work in code which to me has a bad or messy look I feel the strong urge to refactor it. Refactoring it will cost some extra time that may be not planned and so this obviously slows me down.
So I could close my eyes to the ugliness and just do what I came for, leaving the code in at least the same mess it was before. This is a bad idea since there is a good chance that I leave the code in even worse shape that it was before. Why? Because I care less for bad code I did not write in the first place, because I want to get out as fast as possible, because clean code looks odd in a messy environment…
At least I will be slowed down because I keep thinking “Should I refactor this mess? No, I don’t have the time! But it is so terrible…”.
Yes, this is mostly psychological and other people may act less careless than I would, though my experience tells me different.
So at least after leaving the code in bad shape I write a task to refactor it soon. However the product owner keeps declining to give my team extra time to do such tasks (and they keep piling up).
…as a Manager/Product Owner
Good product owners may be listening to the team and grand that extra time to do refactorings. Better product owners will ask how it came to that mess and will ask the team to make sure that it will never happens again.
However not such good product owner will decline. They have a tight schedule for the product and after all there is no business value in clean code, right?
But after some time all kinds of product owners will notice that the velocity of the team is going down, the forecast of features completed for the next release gets worse and worse. Moving in messy code always slows developers down as I wrote above.
I saw some teams whose velocity did not went down while their mess grew. Those teams failed to get a good test coverage and did not do any acceptance testing. So they really did not slow down… in producing bugs!
So if you want your features steady and in good shape you must care about code quality.
…as a Scrum Master
A scrum master is a coach for the team. He or she should help the team to cooperate. Code quality (as defined by the team) is an indicator for the team’s inner cooperation. Show me your code and I tell you how well your team performs. If I find a common style and understanding in that code, your team is in good shape. If I find completely differed solutions for similar problems, different styles and no commentary next to a lot of it, your team is a set of individuals not interested into the work of one another. I know that the first one will produce good and adaptable products, for the second I’m not so sure.
Also a scrum master should also protect the team from impediments. Bad code is an impediment once it is there, so why not keep the team from producing it.
How to Keep Code Quality Up
So keeping the code quality up should be in everyone’s best interest. But how can we detect code quality declines, how can we get a common sense of it?
Definition of Done
The Definition of Done (DoD) is the first step. Get some common understanding of code quality into the DoD. Discuss about code documentation, maximum complexity of methods and classes, the good old tabs-or-spaces fight and write down some rules. If you can give an explanation why you found a rule important and write it down as well. Knowing the reason for a rule always makes it easier to follow it.
So now you got a common understanding of code quality in the team, everyone agreed to the DoD and so everyone will the code quality up, right? Well, it might happen, but it is very unlikely. Rules can be bend, written rules can be interpreted in a way not intended, people can get careless and lazy if it is harder than they thought to comply to the rules… sooner than you know you find all windows broken.
If you are the Product Owner, read your team’s DoD, if you don’t understand the rules ask questions. Do not ever criticise rules if you think they are to complex or to expensive, but try to understand why the team cares about them. If they come to you and ask for extra time to get the rules compliance up, you should know what those rules are and why they are important.
Sometimes rules may be bend and broken for a good reason. If that’s the case, you need to change the rule. Exceptions to rules must be made explicit. Otherwise the exception will weaken the acceptance of the whole rule or even of the whole DoD and you will end up in big trouble.
If complying to a rule takes a lot of effort while its benefit is relatively low you should talk about it and if you cannot reduce the effort it might be a better solution to abandon the rule. Make it explicit by crossing the rule out on the DoD instead of just deleting it and write down why you abandoned the rule.
Abandoning and adapting rules that are hard to comply to is much more important than you might think. A DoD that can be adapted by the team is one everyone in the team cares about. Nobody can say that the rules were nonsense if they were made be themselves.
If you are the Scrum Master of the team encourage adoptions if you sense conflicts.
Code Reviews and Pairing
Even if you have a great common understanding, there can still be misunderstandings how to comply to a rule or the understanding and the motivation to comply may not be as common as you think. In my experience code reviews and pair programming are the only way to detect such issues. Especially pair programming is great in the early phases of a team.
If your team mate has misunderstood a rule you will detect it before it gets into too much code. It does not matter if you are the navigator or the driver, misunderstandings are detected and can be carried out with the rest of the team.
Also there might be rules that are to black or white rules. If you wrote down that you want your code human readable, this rule can be only checked by another human.
Complying to rules must be easy. There are a lot of tools out there to detect rule violations and you should use them. As a Java programmer I use Sonar to visualise violations to the whole team, including the PO and the SM and everyone who is interested. Find some similar to that. It should be fed by your CI the be up to date all the time and it should be accessible and understandable to everyone interested. Tools running on developer machines are definitely useful but having a central system everyone trusts it very important and keeps you from blaming your team mate’s tool.
If you are the Product Owner, keep an eye on the statistics and let the team know that you do. Make the team show them during the review meeting, so everyone can see in which shape the code is. If you are the Scrum Master, make the team talk about the statistics in the retrospective meeting.
As shown there is no long team benefit in abandoning code quality in favour of faster development. There simply is no quick and dirty. There is only dirty and a short time in which there are more features per sprint than before. But after some time the effect will turn into its opposite because the team simply cannot move fast in dirty code.
Even if you think that you can live with that to get your super critical feature out in time, think about the psychological side effects of dirty code. Broken window is a real thing. Fixing broken windows is a frustrating job nobody likes to do. If you still think that you need to do quick and dirty at least you should monitor your technical dept by some tool and let the team produce stories for removing it again. This way you can see how much dept you already have to pay.