The business advantage when developers do less

With a bit of marketing savvy, you can present doing less with less as a superior way of delivering results.

I filched this bit of wisdom from Michael Hugos, who provided the insight in his well-worth-reading book, “Business Agility: Sustainable Prosperity in a Relentlessly Competitive World” (Wiley, 2009).

[ Learn all about the concept of Slow IT. Rant on our wailing wall. Read the Slow IT manifesto. Trade Slow IT tips and techniques in our discussion group. Get Slow IT shirts, mugs, and more goodies. ]

Hugos’ goal wasn’t to do less with less. His goal was quicker results. Fortunately for you and your marketing hat, the two can go hand in hand. All you have to do is stamp out the rampant perfectionism that infests most IT organizations and interferes with the ability to get things done quickly.

As a starting point, a bit of vocabulary that I use in my consulting practice: The difference between “quality” and “excellence.” The “quality” movement has grabbed that word and won’t let go of it, so we might as well accept that “quality” means the absence of defects and conformance to specifications, depending on whether you’re a glass-half-empty or glass-half-full sort of person. (All right-thinking engineers know the correct perspective, of course: wrong-size glass. But I digress.)

The pre-emption of the word “quality” leaves us unable to use it as most of the English-speaking world does — as a signifier of something we think has superior features, functionality, and design. So let’s agree to use “excellence” when that’s what we mean.

If the distinction isn’t clear, back when consumers were complaining about abysmally high rates of iPod failures (one source reported a 5 percent defect rate), it would have been fair to describe the iPod as an excellent but low-quality device.

Or, if this helps, quality is what you notice when it isn’t present; excellence is what you notice when it is.

The distinction has everything to do with doing less with less, because you’re going to start delivering software that has just as high quality — maybe even higher — but that isn’t as excellent as what your developers are accustomed to providing.

That’s because your developers are going to follow Hugos’ advice, delivering software that handles only the 20 percent of business situations that constitute 80 percent of the business volume.

Imagine how much faster developers can develop (or integrators can configure and integrate, if you’re using off-the-shelf software) if they only had to take into account one-fifth of the cases they now code for. That’s one-fifth of the use cases, if you work with use cases. It’s one-fifth of the CASE or IF/THEN logic and one-fifth of the test cases. It might not be one-fifth of the code written, but the result should be a lot less of that, too.

Anything the system can’t handle goes into a manual exception handler, where smart employees figure out what to do with it.

This won’t be hard to sell to your business counterparts. Once they understand how much faster you’ll be able to deliver a solution, they’ll ask why you haven’t been working this way all along. In particular, they’ll be delighted that they won’t have to figure out all the exceptions as part of the “requirements definition” process.

The harder sell will be to your developers, who (1) take great pride in figuring out all the exceptions and ways of processing them, and (2) have built into their unconscious worldview that doing so isn’t optional.

Once you understand the difference between quality and excellence, you’ll be amazed at how often excellence isn’t required.

And, for that matter, how often excellence matters more. For example, J.D. Powers constantly surveys car owners to determine the relative quality of different makes and models. It determines its quality rating through defect rates (and doesn’t do a very good job of even that, by the way).

Since J.D. Powers never asks about excellence, it can’t explain to, for example, Ford, which is getting high marks for quality these days, whether its cars really measure up to the competition.

After all, even during the bad old days when Lamborghinis left puddles of oil on the pavement, their overall excellence meant plenty of car buyers were willing to overlook their lack of quality.

Not that a less-with-less IT practitioner will ever be able to afford a Lamborghini. But at least you might be able to keep your job, which will allow you to make payments on a Ford of your choosing.