Geeks With Blogs

Shelfari: Book reviews on your book blog

.net alternatives by Michel Grootjans

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.

Posted on Sunday, May 15, 2011 12:21 PM Personal , design | Back to top

Comments on this post: Is focusing on quality stealing from the customer?

# re: Is focusing on quality stealing from the customer?
Requesting Gravatar...
I would go in a more pragmatic way: if we are in a hurry, we write some code that is testable but it's clearly not refactored well enough. We note for the next sprint that we need time to refactor this (we accumulate some technical debt), and we refactor then. I find it that the customer wants functionality, that helps him and released often; he doesn't care about code quality. But we should care about code quality as developers because if the code is not refactored properly the next releases will have more and more problems, and thus the functionality delivered to the customer will be less and less valuable for him.
Imposing on the definition of done such an unclear statement as "code refactored well enough" seems to me a bit risky, because the team should have a common opinion on this vague statement which I doubt they will, given we are all humans and have different point of views.
Left by Adi Bolboaca on May 15, 2011 9:16 PM

# re: Is focusing on quality stealing from the customer?
Requesting Gravatar...
- In retrospect, was it worth loosing a teammember over? I'm not implying anyone's fault here.
- Refactoring is presented here as something deferred, while most of the time it's part of the story. I get the feeling that John did not only not share the vision of the team, but was also not into the principles this team holds valuable. This would indicate a missed opportunity to align vision long before you got to this point.
- I would not put it in the DoD, but rather in your team's code of honor.
Left by Yves Reynhout on May 15, 2011 9:42 PM

# re: Is focusing on quality stealing from the customer?
Requesting Gravatar...
It's not worth losing a team member over a disagreement on quality. Maybe an unrealistic timeframe was set in the first place? Having said that, if someone is going to walk then you are probably better off without them.
Left by Kiwishaver on May 16, 2011 12:41 AM

# re: Is focusing on quality stealing from the customer?
Requesting Gravatar...
On the surface of it, I think I hold more in line with John's view than the team here.

It is not the team's decision to define "done" - that is very clearly a business decision. It sounds like the team made the decision they felt met their ideals independently of the business.

John had a different style/opinion on the code base - his definition of "done" was clearly different to others. And if there is that much of a disagreement, then parting ways is probably best.

But, I suspect the failure here was the team's failure - not John's.

If you can't argue convincingly and rationally for your new version of stories and what "done" means, then maybe you should re-evaluate if you are actually correct. Either way - you shouldn't lose a team member over it - so I suspect he also had a lot of other disagreement's over your approach too.

Maybe you should have got the business involved and asked what *their* definition of "done" was?

Left by Jak on May 16, 2011 1:22 AM

# re: Is focusing on quality stealing from the customer?
Requesting Gravatar...
Checking in code that just works always bites you in the ass in the long run!

A lot more time is spend on reading, debugging and interpreting code than it took to initially to write it. And if the code is not readable, then you loose a lot of time on this and then you're really stealing from your customer. Not only now, but also in the future, even long after the deadline is passed. Then someone else needs to maintain the code and he is spending even a lot more time to understand it. Then that person leaves, after leaving some more code that just works, and so on... After x years you end up with a nice product that works like a reverse cash cow. I've seen this happen more than once.

But I agree that the definition-of-done for the development team should be defined in agreement with the business people. And if they propose to drop quality, make them aware of the consequences.
Left by Pascal Mestdach on May 17, 2011 4:47 PM

# re: Is focusing on quality stealing from the customer?
Requesting Gravatar...
Good code won't make projects fail, but it might scare off a certain type of client, when presented with the increased time and budget demands required to do a "quality" project. Also, it will frustrate a certain type of developer who might be considered to be an "efficient" worker at other places - they can no longer keep bad code hidden.

Long-term success with this strategy absolutely depends on to the quality of your account and project managers. They must be prepared to defend quality over speed at all times. If they compormise even once, either the clients or the developers are going to end up very, very frustrated.
Left by Bjorn Verryt on May 20, 2011 9:55 AM

# re: Is focusing on quality stealing from the customer?
Requesting Gravatar...
I know, I'm slow to the game...

Definition of Done belongs solely to the team. There is an underlying assumption that "Works" is also a part of that definition. DoD is a summarized set of quality attributes that ultimately dictate processes the team will follow (e.g., there must be unit tests that all pass, must be deployable to stage, etc). As long as the DoD doesn't negatively impact velocity and business user is receiving business value, I don't see the problem here.

On the other hand, there is "right sizing". If an application is expected to be completed on a short time frame and for cheap, then we really can't have the processes we want as delivery folks. Good, cheap, fast; pick two.
Left by Tim on Feb 22, 2012 2:26 AM

Your comment:
 (will show your gravatar)

Copyright © Michel Grootjans | Powered by: