|
|
Re: The Code Quality Myth
|
Posted: Mar 1, 2005 9:58 AM
|
|
> > You just illustrated the point I was trying to make:
> Even
> > though your cell phone crashes, you still find it
> useful.
> > In fact, you yourself support that less-than-perfect
> cell
> > phone software by subscribing to the service month
> after
> > month.
>
> If I had a better option that cell phone would be history.
> It galls me that I don't have a better option.
>
> We are knee deep in crappy software. The bar has been set
> so low that we *accept* it, and *plan* to build more of
> it. I find that unprofessional. I do not accept that it
> is ever necessary to build crappy software.
>
You sound very much like Scott Meyers two years ago. This is the reason he wanted to bring people together at a meeting on Writing Better Code. He was both frustrated with buggy software he had to use every day, and with the low quality of code that exists despite the knowledge that exists about what quality code looks like. One of the topics of discussion was that given we know how to do it, i.e., examples of good code is published in books and articles, why are people creating bad code? Actually, Scott was also frustrated by bad examples that make it out to the public in books and articles, too. And we all agreed that even if that process could be fixed, that a significant percentage of people doing programming would not see them because they don't read books on programming or go to websites like Artima. So they wouldn't necessarily get the memo.
> People sometimes build crappy software because they think
> building crappy software is faster than building good
> software. They are wrong in my opinion. It is faster to
> build good software. This is the essential value of a
> professional.
>
It's been said by others here that in general people don't decide to build crappy software, they just ship it before they get it better. It is not unprofessional to need to refactor. The first time you write something in human language it is called a rough draft, because you need to go back and edit it a few times to clean it up. It is even good to let it sit in a drawer unseen a week, because looking at it with fresh eyes helps you see opportunities for improvement you didn't see before. It especially helps to have others look at it (editors and reviewers) and assist. But all these things take time, and at some point you need to ship it. That's true for an article, and it is true for software.
Let me tell you a story I overheard a couple years ago at a local Starbucks here in Silicon Valley. Two executive-looking guys were sitting at the table next to me. These guys were talking loudly enough that I couldn't help but eavesdrop. One fellow had apparently been at WordPerfect Corp back in the days when Windows 3.0 or 3.1 came out. He said that WordPerfect had a version of their word processor for Windows that they considered releasing when the new OS came out, but it had a lot of bugs in it. The higher ups at the company decided to delay releasing it until it was in better shape, presumably because they didn't want to tarnish the image of Word Perfect with a low quality product. Microsoft, however, went ahead and released Word for Windows, "with all the same bugs," as he put it. Word Perfect took eight months to clean up their product before releasing it, and they lost 5% market share *each month* to Word.
The moral of the story that the guy seemed to be trying to get across (to his companion, not to me) was that WordPerfect would have been better off as a business if they'd released the buggy Windows product eight months earlier, then released a cleaner one eight months later. That they would have lost far less market share those eight months. I think in this case, people who bought Windows preferred to buy a buggy word processor with a Windows-GUI now to a more robust word processor with a DOS-GUI now or a word processor with a more robust Windows-GUI later.
The other assumption I believe you seem to make is that there's a strong correlation between code/design quality and product quality. I do agree there is a correlation. I've seen horribly unstable and incorrect programs that when you look at the code, you see it is jumbled confused mess. This is F-grade code producing an F-grade user experience. But I've also seen F-grade code cleaned up to about the D-grade level that gives B-grade user experience. I believe C-grade code can give an A-grade user experience: the present code is stable when running today, but fragile to change in the future. I also believe A-grade code can yield a C-grade user experience, for example, if there are other external issues like hardward insufficiencies or configuration problems. So my take is that although there is a correlation between code and product quality, it is a weak correlation.
> I recently bought an IMac. I turned it on, and it worked.
> It doesn't crash. It's easy to operate and easy to
> o configure. The hardware is beautiful. They put a lot
> of thought into it. It's a truly wonderful machine.
>
> My next laptop will be a MAC. My daughter is in college,
> and so I'm going to get her a MAC. Many other people I
> know are making similar decisions.
Sounds like an Apple switch commercial. I did the same thing four years ago, but not because of quality concerns. I wanted to run Unix on my laptop, because I find I am more productive and happier on Unix than DOS. My style of development is that I use the command line a lot, and the design center of Windows is that you use the GUI all the time. DOS drove me nuts, and I just wanted Unix. I also wanted to run FrameMaker+SGML, which only ran on Windows and the Mac. Adobe actually had released a beta version on Linux, but didn't release it ultimately as a product. So I figured I was going to have to dual boot between Windows and Linux.
One fine day, just after OS X was first released, I saw Ken Arnold running Jini on a Mac laptop running OS X. He then showed me the Unix shell, and I realized this was the perfect solution to my problem. I could run Unix, and all the free software that's available in that community, and without rebooting run commercial software written for the the Mac, such as FrameMaker+SGML. And I could finally get off of Windows, where I never felt at home. So I took a deep breath and bought a Mac laptop.
I had always thought my friends who were Mac fanatics were a bit odd, but once I started using my Mac, I realized it was really very pleasant to use. A joy to use, actually. But that wasn't why I bought it. I bought it because it ran the applications I wanted to run (Unix and FrameMaker+SGML in particular).
Some people have posted in here about cars in the 70s. My likely naive theory of what happened in the 70s is that the Japanese saw quality as a competitive opportunity, and went for it. And it worked. And once American manufacturers saw that the Japanese were eating their lunch with better quality cars, they figured out how to improve the quality of their cars too. And we have all benefited as consumers. For this to work though, it was important that the switching costs were low for cars. I can drive a Buick this year, and a Toyota next year, and there's no significant cost for me to switch. With operating systems, the switching costs are much higher. If I've invested $2000 on software that runs on Windows, for me to switch to the Mac, I have to somehow replace that software. That makes it much more expensive to switch, and harder for a challenger to compete on quality. That in turn means the incentive is lower for businesses to create quality products.
Lastly, it is not always possible for consumers to really get to know the quality level of a software product or service before they buy it. When I selected my cell phone, for example, I didn't realize that having a single button for answering and hanging up would cause me to hang up on a lot of friends accidentally. In practice, sometimes I would forget to lock it when I slipped it in my pocket. It would ring, I would grab it, but in the process of pulling it out of my pocket, the answer button would be pressed. This would answer the phone and toggle the answer button to mean hang up. Then I'd proceed to attempt to answer the phone by pushing the answer button which now meant hang up, and hang up on the person. My point is that it is hard to compete on quality when customers can't figure out the quality before they buy it, and when they have a hard time comparing quality of your product to others.
|
|
Previous Topic
