Comments on: Creating a Culture of Quality

By: Fervent Coder

Fervent Coder — Thu, 12 Jun 2008 04:15:58 +0000

This is awesome! I have something like this in my queue of topics. Make it easy applies all the way across for me. In every aspect of development, make it super easy. Make it easy for the guy that just got called in at 10PM to fix your code. He shouldn’t have to give you a call if it’s easy enough. I just wrote a post about developing with quality in mind, but from more of a maintenance standpoint. I think it follows the same lines, but from a little different perspective.

http://ferventcoder.com/archive/2008/06/11/develop-for-maintenance.aspx

By: jcteague

jcteague — Sat, 07 Jun 2008 17:41:07 +0000

@Jason
Excellent point and should probably be the first item on my list. Pairing is the best way to not only ensure quality, but to keep the level of profeciency on the team high. I think that deserves a blog post to itself.

With the exception of R#, I try not to depend on tools too much either. My point was that there are some low friction, easy to use tools that will make it easier to keep a high level of quality in your code. But this is making an assumption you are taking care of the “people” aspect first.

Thanks

By: jcteague

jcteague — Sat, 07 Jun 2008 17:36:41 +0000

@Uncle Bob
Your Point is well taken and there is always a trade-off. Then answer is of course it depends. I’ve been in situations where a bug was reported early in the project and it just sat on the board while other, more interesting tasks were worked on.

Now if you’re near the end of the project and you’ve got to get XYZ done before you go live, that is a judgement call. But I fear if you continue to let bugs show up on the board without addressing them you are accepting a level of mediocrity that will eventually lead to a mediocre product.

Thanks

By: Jason Meridth

Jason Meridth — Sat, 07 Jun 2008 11:25:02 +0000

John please be very careful with this mindset because it can lead to putting tools over people. I did it myself for a while.

The agile manifesto states, “Individuals and interactions over processes and tools”.

To ensure the greatest quality, talk to your people, pair program with them. Ensure that they don’t have fear by letting them know you won’t judge their code or yell at them if they break the build. Don’t let a sound or flashing device speak first.

If your suggestions are after you have successfully conquered the people aspects of quality, then I completely agree they are valuable next steps.

In agreement with you about the CI tool and it’s communication back to the team:
We use the mortal kombat sounds in our lab.
Successful build = “Flawless Victory”
Fixed build = “Excellent”
Broken build = “Fatality”
Continuous Broker Build = “Get Over Here”

When we here the broken build noises, at lest 2-5 developers are bringing up the CC.NET web dashboard to see what happened. We’re trained that we have to tackle it immediately.

By: Uncle Bob

Uncle Bob — Sat, 07 Jun 2008 03:05:14 +0000

” If there are any reported bugs on your task board, you finish those before starting a new story.”

Really? Even if those bugs are minor and are less important than other features that customers are asking for? I understand the point that you are driving at, but I see many developers put building perfect software as their primary goal and put the needs of the business or the customer as a secondary goal. I’ve been in meetings where there has been a bug that has affected 1-2% of our customers in a minor way and developers get quite upset about not having the time to refactor and rebuild that portion of the code because it was decided that implementing a new feature that was requested by 70-80% of customers and represented additional revenue for the company, not to mention a competitive advantage.

So while I agree with you and I’m probably splitting hairs, there is a time when it’s ok to leave bugs and focus on other stories.