So, here it is, Sunday, and I’m getting ready to hit the road again (where I spend half my life anyway), whip out the old notebook, click on the workgroup icon, and – that bizarre Windows XP error message that inexplicably creeps in from time to time about
At Network World’s IT Roadmap events this year, I’m presenting a kind of “Top 10” list of issues in wireless and mobile for 2008, except that there are 12 of them, and one of these is this whole issue of product quality. All too often, products that just don’t work, or, in my current case, just stop working for no apparent reason, result in serious aggravation that customers just don’t deserve. Sure, it’s a computer, it runs an operating system, there’s an inherent degree of complexity associated with all of this, to be sure, but that’s the environment, not an excuse to produce products that cost way more (CapEx, but especially OpEx) to use than they should. How much time is wasted every day, around the world, dealing with strange issues that stump even computer science majors, performing countless updates that require time-consuming installations and reboots, all because someone couldn’t get it right the first time? And how many minor (or somewhat greater than minor) disasters occur because these ridiculous problems occur when someone is on the road – in other words, right before the big presentation, or the report is due, or the air reservation needs to be changed?
And who is that someone – who should take responsibility here? Years ago, I gave a talk on what I’ve since been calling lazy and/or incompetent programmer syndrome, or LIPS. We all know people who shouldn’t be let near a COBOL coding pad, and, yet, here they are unintentionally spreading mischief and clueless that they are doing so. But I no longer think that’s the problem. Just as we shouldn’t blame the guys on the assembly line who turned out poor-quality mechanical products (as was the case with the US auto industry especially during the 1980s), we shouldn’t blame programmers, at least most of the time.
Rather, the responsibility rests with the managers who, at least with respect to software produced by corporations, seem to be lazy, incompetent, or perhaps even evil (and such thus leads to the term LIMS, or even LEMS). Lazy I can understand. Evil I have a hard time with.
And where might evil possibly fit in software development? Consider the possibility that some software is simply designed to be so complex as to lock out competition – designed first and foremost to make money and preserve monopoly, and only secondarily to serve a customer. Heck, a company in that position could ship positively anything and probably sell a lot of it, bug-ridden and error-prone and unsupportable as it is, and basically ignore complaints all the way to the bank. Competition is thus essential to ensuring at least the possibility that you and I won’t have to go through another day trying to debug a problem that shouldn’t even exist in the first place. That’s why I’m migrating (slowly, unfortunately) to LINUX and the Mac for all future portable devices – and eventually all the computers we own.
Yes, you evil managers, you know who you are. And you can do better. I insist.
