أخبار
The business advantage when developers do less 
8/1/2009
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.  
4