Quality, Revisited

Wow, that was a lot of great feedback in a few hours.

So let’s talk about it.

The first thing I want to talk about is the tone of the piece. It’s kind of idealistic. Of course, things didn’t always go that smoothly, but we aspired to meet the standards we set for ourselves. And things were definitely improving everywhere you looked. syl commented on how the TV screens were mostly red. This is actually true at a lot of places that measure build breakages, because keeping all 200 builds green at all times is an absolute nightmare. Especially when a lot of them are hitting a test web server with Internet Explorer 6 and WebDriver, trying to break your application. You might break the application, or you might simply break IE.

This got a lot better when we made the (painful) upgrade from Selenium 1 to Selenium 2 + WebDriver, by the way. If you’re running anything through Selenium, I wholeheartedly recommend you take the hit—your browsers will become so much more stable. When I visited TIM Group recently, everything was looking nice and green.

Andrew Parker asked what the question was that prompted the piece. It was in an email from Ed: “Basically I wanted to know what process (Agile, Kanban, Waterfall???) you follow and what tools you may use to help (JIRA, etc)? Any books/resources you can recommend too?” I replied with an answer, but I was dissatisfied with it, so I blew it up by a thousand words or so and made it into a blog post.

Finally, David Green pointed out that the dogma on the cost of fixing bugs has been debunked by Laurent Bossavit in his book, The Leprechauns of Software Engineering, along with other myths and legends. I’ve added it to my reading list and I’m really looking forward to it.

Thanks so much again to everyone who retweeted, commented and gave advice on the post. I really appreciate it.