The Artima Developer Community
Sponsored Link

Weblogs Forum
The Code Quality Myth

46 replies on 4 pages. Most recent reply: Jul 16, 2012 6:12 PM by 83011

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 46 replies on 4 pages [ « | 1 2 3 4 | » ]
Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: The Code Quality Myth Posted: Feb 26, 2005 10:46 PM
Reply to this message Reply
Advertisement
> 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.

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.

I recently bought an IMac. I turned it on, and it worked. It doesn't crash. It's easy to operate and easy to 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.

Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: The Code Quality Myth Posted: Feb 27, 2005 12:02 PM
Reply to this message Reply
> 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.
>
> 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.
>
> 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.

We wouldn't be anywhere near where we are now in terms of number of people who use computers if it weren't for Windows and Intel PCs. Were they crappy? Yes, especially compared to the elegantness of Macs. But they were much more affordable and they did enough for most users (i.e., word processing and Internet surfing). I don't think we would even have an Internet community like today's if there would have been only high-quality computers like Macs.

Windows is not even so crappy anymore. With Windows XP, gone are the days when I had to reboot every couple of days.

So mark one down for delivering low quality that was good enough for its time and improving it later.

Bill Venners

Posts: 2251
Nickname: bv
Registered: Jan, 2002

Re: The Code Quality Myth Posted: Mar 1, 2005 12:58 PM
Reply to this message Reply
> > 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.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: The Code Quality Myth Posted: Mar 1, 2005 3:46 PM
Reply to this message Reply
> We wouldn't be anywhere near where we are now in terms of
> number of people who use computers if it weren't for
> Windows and Intel PCs.
...
> So mark one down for delivering low quality that was good
> enough for its time and improving it later.

No, mark one down for impeding the industry for a decade.

Windows did not have to be crap. Why do we accept that since it *was* crap, it *had* to be crap?

If Microsoft had done a better job they would have given us more, given it to us sooner, won our hearts and minds, and obliterated any possible competition.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: The Code Quality Myth Posted: Mar 1, 2005 3:50 PM
Reply to this message Reply
> 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.

Word Perfect would have been better off as a business if they had kept that code clean enough to ship at any time.

The moral of the story is: "Don't let your software get buggy. Keep it clean at all times."

Bill Venners

Posts: 2251
Nickname: bv
Registered: Jan, 2002

Re: The Code Quality Myth Posted: Mar 1, 2005 4:46 PM
Reply to this message Reply
> > We wouldn't be anywhere near where we are now in terms
> of
> > number of people who use computers if it weren't for
> > Windows and Intel PCs.
> ...
> > So mark one down for delivering low quality that was
> good
> > enough for its time and improving it later.
>
> No, mark one down for impeding the industry for a decade.
>
>
> Windows did not have to be crap. Why do we accept that
> since it *was* crap, it *had* to be crap?
>
> If Microsoft had done a better job they would have given
> us more, given it to us sooner, won our hearts and minds,
> and obliterated any possible competition.

I agree with that. When I was using Windows 98, which was the last version of Windows I used before switching to OS X, it crashed about 3 times a day. It drove me nuts. I really don't believe that it was at all necessary for Windows 98 to be that buggy to meet the Windows 98 market window. Although I suppose it would be rather embarassing to release Windows 98 in 1999. Similarly, I don't believe it at all counted against Apple that they took a lot of care about the user experience. If Apple had decided to license the Mac OS in 1985 the world might be very different today.

My point is not that it is necessary to push crap out the door to meet market windows, but that sometimes it doesn't matter what quality you push out the door so long as you hit the window. That isn't an excuse for poor quality, but it is an explanation as to why it happens.

I don't know, because I've never worked at either Apple or Microsoft, but my impression is that Apple's culture is one that cared very much about the quality of the user experience, and Microsoft's culture was one that cared very much about the quality of the market share and business model. Microsoft has a very quality business model, and nowadays I think their user experience is much better. I don't use XP regularly, but my impression is that they have made great strides in improving the quality of the user experience. The other problem that Microsoft had that Apple didn't was dealing with a great deal many more flavors of hardware, precisely because they did license their software to everyone and Apple didn't. But despite all that, I think there is something about Apple's culture that yields these elegant, simple and pleasant to use products. I would love to understand better how they do that.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: The Code Quality Myth Posted: Mar 2, 2005 9:40 AM
Reply to this message Reply
If crappy code was *really* acceptable, the average traditional software development project would not be spending 50% of its project time in the bug-fixing (aka "testing") phase.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: The Code Quality Myth Posted: Mar 2, 2005 1:43 PM
Reply to this message Reply
> > Therefore 'quality' is not a property of the
> > code but is a property of the programmer's analysis of
> > that code.
>
> What you just write nails this issue exactly: "Code
> quality" is not a property of the code per se, but is a
> concept formed in the head of programmers working on that
> code.
-snip-
> Yet, he consistently produced very high quality code in
> terms of the code performing exactly to specs and without
> defects.

"Code quality" is a slogan.

When we intend to have a meaningful discussion, we say what we mean by the slogan and confirm that it's been understood.

Suggesting that one notion of code quality includes conformance to specification and defect rate, is a start.

For a useful notion of code quality we also need to say how each of these factors will be measured, and where to put the dividing-line between high/low.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: The Code Quality Myth Posted: Mar 2, 2005 2:07 PM
Reply to this message Reply
> I agree with that. When I was using Windows 98, which was
> the last version of Windows I used before switching to OS
> X, it crashed about 3 times a day. It drove me nuts. I
> really don't believe that it was at all necessary for
> Windows 98 to be that buggy to meet the Windows 98 market
> window.

Should we take a moment to wonder why "it crashed about 3 times a day" - maybe it was the third-party device drivers.

In "Software Assessments, Benchmarks and Best Practices" Capers Jones says that very bright generalists (Microsoftees) can build low-end applications (<1,000FP) in a semiformal way and get away with it most of the time. That doesn't work for major systems (10,000-1000,000FP) like Windows 98. p429-431

"There are hundreds of successful ways to build small applications, but only a few ways to build large systems successfully." p431

"LINUX is currently less than half the overall size of Windows 98..." p431

Guru

Posts: 1
Nickname: mogli
Registered: Mar, 2005

Re: The Code Quality Myth Posted: Mar 13, 2005 8:20 PM
Reply to this message Reply
I partially agree with you. The code with no quality has it's own set of problems. By following some percentage of quality procedures while coding would reduce a lot of issues.

Tom Chou

Posts: 2
Nickname: tomthefat
Registered: Dec, 2005

Re: The Code Quality Myth Posted: Dec 6, 2005 8:04 PM
Reply to this message Reply
> Another way to look at it is that, say, you're now
> spending an extra $1000 per month because of the ugly
> naming conventions. To clean that up would cost, say,
> $5000. So spending $5000 now would result in a cost
> reduction of $1000 for each month after the job is done.
> Now, suppose you could spend that $5000 on creating a new
> feature instead that could generate you $2000 per month.
> How would you spend your $5000? If you spent it on the new
> feature, you could be ahead $1000 per month, even if
> living with the ugly code. I know that this is a headache
> for developers having to maintain that code, but that's a
> reality anyone with fixed resources has to deal with.

No, no, no. Having poor code quality could raise the cost much more than that.
Moreover, spending the money on adding features instead of code cleaning could make your program even worse.
If you do not clean the code before adding new features, how can you sure the new feature will work ok ???
It could mean bringing further chaos.

Tom Chou

Posts: 2
Nickname: tomthefat
Registered: Dec, 2005

Re: The Code Quality Myth Posted: Dec 6, 2005 8:16 PM
Reply to this message Reply
You talked about the importance of processes, I agree.
Certainly the software process is highly important in the software development.

When you said code quality does not matter, I totally disagree. What you said applies more to manufacturing than to software. Software is different from manufacturing.
In software, the maintenance could be up to 80% of total cost. In manufacturing, there is no such thing as maintenance as used in the software sense.

If you had experience in software development, then you would know the importance of code quality.
The software quality factors of Maintainability, Reliability, etc. relate closely to code quality.

Richard Jonas

Posts: 147
Nickname: rjonas
Registered: Nov, 2005

Re: The Code Quality Myth Posted: Dec 12, 2005 4:48 PM
Reply to this message Reply
As has been said, most customers only look at your binaries, and code quality is important if and only if someone is going to need to maintain it. The difficulty is that when you write something, you often don't know this. It's important to make things as readable as you can without slowing down the development too much. Think about the variable and function names you use for example.

However, if you do revisit your code or someone else's code, if it's not obvious what it does, you should write some tests around it to clarify exactly what it does, refactor it so you are better able to make your changes. If everyone does this, the code quality will then improve in the areas that are often revisited, where it needs to be its highest.

If you just try and change the existing code without refactoring it, the quality will gradually get worse, and the maintenance times longer and longer.

Richard Jonas
Blog: http://www.richardjonas.com/blog
Web Site: http://www.richardjonas.com

Josh Friedman

Posts: 3
Nickname: jdfphilpa
Registered: Dec, 2005

Re: The Code Quality Myth Posted: Dec 15, 2005 9:50 PM
Reply to this message Reply
The company that I work at outsourced the porting of a GUI that was originally written in C++ using CGI, to Java / J2EE. The outsourcers got it done in three months. Considering that there are over 1000 classes and hundreds of JSP's, that's pretty impressive, eh? Allowed us to get to market faster and all that, and rake in the bucks. And since those programmers in India are paid far less than programmers in the U.S., we saved lots of money on development - maybe we can even lay off a couple folks that have families to care for!! But, did we really save on all of the costs?

The code was turned over to our team for maintenance. I had to make a relatively minor change to several Struts action classes. I found several chunks of logic that were cut-and-pasted over and over again, across several classes. In one case, a 5-line block of code was repeated 24 times, differing only in a hardcoded array index. So, if there's a bug in that 5-line block, do I have to fix it 24 times? And, if there's a 50-line chunk of code cut-and-pasted amongst 5 classes, do I have to fix that bug 5 times? And, if I have to modify said logic to add a business feature, should I add it 5 times? That is what you are advocating! Oh, and oops...it was in 6 classes, and it took me another month to find that 6th class...

To top it off, the code is formatted badly - crazy indents or no indents, so that you cannot see the structure of the code. They used Eclipse, which reformats code with a single keystroke - they did not bother to do that!

It is absolutely demoralizing to me that our management accepted such shoddy work and praised the outsourcer. Me and my coworkers have to face the consequences of this work.

Even if we turned the code back to the outsourcers for maintenance, they will face the same problems - the time they saved initially by doing the cut-and-paste will come back to haunt them. The product will get buggier and buggier, customers will get increasingly frustrated, and will eventually turn to other vendors. Short term savings vs. a very dear long term cost!

There is more than just money involved. There have been a number of posts that try to justify one approach or another monetarily. There is a limit to that. At some point, we have to consider how we are treating the people that we manage. We have to consider costs other than monetary - we have to consider the human costs. Allowing and encouraging people to write good code is humane. We have forgotten all about humanity in this money-driven country, and the cost is terrible. Re-read your eXtreme Programming books - what comes through is humanity, caring about your coworkers, the team that you manage, as people, not as cogs in a moneymaking machine.

Gary Heller

Posts: 1
Nickname: bwanagary
Registered: Feb, 2006

Re: The Code Quality Myth Posted: Feb 15, 2006 5:30 AM
Reply to this message Reply
What a shame. The word "maintainability" doesn't appear anywhere in the author's article.
A) Code quality improves application reliability and maintainability
B) Facilitates automated testing
C) Confidence level in the product
E) Reduces time in finding bugs
F) Provides a metric for productivity vs. volume
G) Helps managers assign tasks to developers - critical portions go to the better developers.

Over the last 25 years an enormous amount of energy and money have been spent making "computer programming" easier, and accessible to the masses. As languages like Java, C#, Visual Basic and others, IDEs like VisualXXX (ms), Borland JBuilder etc., and the advent and accessibility of the Personal Computer have made "programming" easier, a great influx of individuals with less exceptional aptitude have entered the fray, producing an enormous volume of code. Software quality monitoring becomes a requirement given the less stringent criteria for being a "programmer". Notice I do not call them software engineers or developers, who do more than sling code.

"Quality" software speaks to code organization, and the organized thinking of its author. Quality speaks to personal integrity and pride. It speaks to the technical "hygiene" of the author. It speaks to the mentorship that they received - no professor of repute will battle through miles of undisciplined and unstructured spaghetti code.

The author is correct in that code quality is only one part of the process that delivers a quality product, but a chain is only as strong as its weakest link. Product development is a whole orchestration - any developer producing sour notes spoils the concert.

I personally would rather fly in an aircraft with navigational and computational systems that had passed rigorous quality control, at the code level inclusive, than on an aircraft with software and firmware developed by Dennis Nedry (Jurassic Park), however brilliant it may be.

Flat View: This topic has 46 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Traps & Pitfalls of Agile Software Development - A Non-Contrarian View Previous Topic   Next Topic Topic: Windows 7 Client for NFS Grief and Solution


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us