Defects, Deadlines, Disaster

Cutting my hair taught me about quality.

“Can you tidy up my hair?” I called to my wife, sporting a freshly shorn head.

As my wife entered, she groaned. “Did you even try? You missed so many spots you look like a sea urchin.”

“I only had 10 minutes - we’ve got to leave for your cousin’s wedding!”, I retorted.

“You spent 10 minutes making all these mistakes that I’m going to spend 20 minutes finding and correcting. I’m only going to do this because I prefer to be late, than to walk alongside a sea urchin.”

Something in my head clicked.

In organisations, we often pay thrice for software defects. We pay for defects to be made, caught, and then corrected. This is expensive.

An alternative approach is to prevent defects from being made in the first place by uprooting their common causes.

One common cause is setting due dates for projects.

Ian Larsen reminds us that software development is a creative endeavour. Whilst we know the impact we want the software to have, it’s not possible to precisely predict the necessary feature scope, time, budget, and quality to get there. We discover these along the way.

However, we often inadvertently cement all four of these - feature scope, time, budget, quality - at the start of a project, when we know the least.

We may ask a team: “Please deliver these features, by this due date. Don’t be late!”

Thus, we cement scope and time.

Budget usually equates to the project team size. Finding more staff takes time, so in the short-term team sizes are fixed. Furthermore, Brooks’s Law reminds us that “adding manpower to a late software project makes it later”.

Thus, budget is cemented.

We also don’t want to take shortcuts and reduce quality in software development. Like building a house with low-quality materials, all future maintenance of the software would become costly.

Thus, quality is cemented.

But, if software development is uncertain, and we’ve attempted to cement the feature scope, quality, time, and budget we think we need to get there - then we’re going to be wrong. And, what happens when we find we’re wrong?

Suggests Ian: “Quality breaks first. This is because it's the hardest thing to measure and control.”

Thus a torrent of defects are created, that must then be caught and corrected. This takes time and money, and delays projects.

The takeaway? Don’t fix defects, prevent them. Forcing a project to predict the unpredictable will only cause more defects, leaving you with a bad hair day.

This article was inspired by Ian Larsen and Clarke Ching.