We had a crisis in our team last week. One of our teammates left.
It all started off with a discussion while pairing on a task with John (not his real name). I found a method did not belong in a certain class, while John didn't care, but didn't want to change it. We started a discussion that ended up into a heated debate about code quality. The two positions were:
- having readable code leads to a higher velocity
- checking in code that just works gets us to the deadline
During the sprint retrospective, this event got a lot of attention, and we decided to see if we could modify our Definition of Done to ease this kind of discussions. We tried to come up with a short description of an activity that would not be too constraining, while keeping the focus we wanted.
"Commit code that is readable enough for three pair of eyes"
John found that this activity did not belong in the DoD.
John's argument can be summed up as this. When code works, the customer is happy. The customer doesn't see the "quality" of the code, and he doesn't care. Code quality is subjective. Beauty is in the eye of the beholder. We have deadlines to meet, and these should be our first priority. Refactor code when you have time. On a Friday afternoon after a retrospective, when you're not in a hurry to jump into the next traffic jam. So if the code is not looking good enough, so be it. Move on.
The team voted to add this activity to the DoD of a user story.
The team's point of view is that a story is not done until it is refactored well enough. This implicitly means that a story that works, but whose code is not good enough, will not get released and its points will not be added to the sprint's story points. This story will be taken to the next sprint, just to clean it up.
This is the point where John decided he could not function properly in a team that held such a point of view.
I find it amazing that a professional would quit for this reason. People usually quit because they want something better than what their current position has to offer. What is this 'better' John is looking for? Maybe this was some kind of resistance to change.
I have seen plenty of projects slowing down month after month, just because of poor code quality. But I have yet to see a project fail because too much attention has been given to code quality.
"The only way to go fast is to go well" -- Bob Martin.