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 | » ]
Michael

Posts: 12
Nickname: target
Registered: Jan, 2005

Re: The Code Quality Myth Posted: Feb 25, 2005 8:38 AM
Reply to this message Reply
Advertisement
>> Code quality is but a small part of that effort. An
> organization can get a better return on investment from
> focusing on the processes that lead to a quality product,
> than by placing a great deal of emphasis on code quality.

Sorry, I don't see any difference. Many agile practices (Refactoring, TDD, PP, KISS, etc) improves code quality and I think this is one of the main reason why they are so popular.
By implementing these process you will improve code quality for sure. Where is the difference you are tolking about?

> Managers, intuitively or by learning, seem to understand
> that - to the chagrin of developers, who must work on the
> level of the code day after day. That's sad news, because it
> means that we, developers, are doomed to eternal complaint
> and frustration about code quality.

This is a part of old discussion about how code quality affects team performance and so on. Good managers understand that good code is an investment. It could bring *only* long term benefits. So possible strategies are clear. If this is "throw-out" project - hacking is possible and acceptable (well, even in this case you never know the future of the project). If this is a solid long-term project code should be good, and manager should support team to write good code.

Michael
http://blog.targetprocess.com

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: The Code Quality Myth Posted: Feb 25, 2005 8:56 AM
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.

That's fine if you can live with the run-on effect. Too often I see teams that simply can't deliver in a timely fashion because the code has gotten so bad. They've pissed away their internal quality and now the business is left with an extremely expensive ball and chain around its ankle.
The opportunity cost of the time they spend wading through bad code is enormous.

And, that's the issue really. You can use the Deming model to say that the binaries are the most important thing, but the fact is, for nearly all software development, sustainability is the most important thing. We address source code quality for exactly the same reason that we address the assembly line in manufacturing. Delivering the first car but increasing the costs of making the second and third is not a way to win. In other words, it is more than the first release.

Michael

Posts: 12
Nickname: target
Registered: Jan, 2005

Re: The Code Quality Myth Posted: Feb 25, 2005 9:06 AM
Reply to this message Reply
> Delivering the first car but increasing
> the costs of making the second and third is not a way to
> win. In other words, it is more than the first release.

Yes, this is very true. I completely agree.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: The Code Quality Myth Posted: Feb 25, 2005 9:24 AM
Reply to this message Reply
> > My cell phone crashes from time to time. I care about
> > that. I want it to stop crashing. I don't want to
> have
> > to reboot my phone. Sometimes the crash is so bad that
> > the software has stopped polling the off switch, and I
> > have to pull out the battery. I care about this. I
> wish
> > it didn't happen. I swear at the programmers every
> time
> > it happens.
> >
> > Every time windows crashes, I swear at the programmers.
> > Damned unprofessionals!
>
> 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.
>
> I have had to deal daily (I mean *many* times a day) with
> customers who had one or another kind of problems due to
> Windows. Just today, I spoke with a customer who was
> literally ready to murder because he lost a customer due
> to viruses and spyware that rendered his computer useless
> at a crucial moment. Yet, this very customer, and millions
> like him, support that OS because, on the whole, they
> still find it more useful than using a pencil and paper.
> If the vendor of that OS waited for the iterations to
> reach defectless quality, this customer would still be
> using paper and pencil. On the contrary, this company made
> more money than anyone else in history by knowing just
> what the lowest tolerable quality was to ship their code.


Be patient. If I substituted nouns you could be talking about the U.S. auto industry in the 70s. And we know what happened when we didn't focus on quality.

Watch India and China if you believe it won't be a problem for current software manufacturers.

The lesson learned in manufacturing over the last 30 years is that extremely high quality bars make development faster. That is the lesson we have yet to learn as an industry.

Ravi Venkataraman

Posts: 80
Nickname: raviv
Registered: Sep, 2004

Re: The Code Quality Myth Posted: Feb 25, 2005 9:47 AM
Reply to this message Reply
Frank Sommers said, "That's similar to a cluster of commodity PCs: Each node might not be of very high quality. But the cluster software, the system as a whole, is highly robust."

I do not believe that that is a fair analogy. The PCs are essentially interchangeable pieces that deliver the same functionality. Code written by two different programmers working on different pieces is not interchangeable.

If two (or more) programmers are writing the same piece of code, then there is a bigger problem.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: The Code Quality Myth Posted: Feb 25, 2005 11:39 AM
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. And, indeed, "improving" code quality for someone, may be a "decrease" in quality for someone else.

I have a friend, for instance, whose taste greatly differs from mine - he prefers elaborate, highly ornate things, whereas I prefer simplicity. When I visit his home, I feel overwhelmed by his design choices; and he probably feels out of place when he comes over to my place. I worked with him on a few coding projects, and I didn't like his choice of design, naming conventions, lack of abstraction, etc. Yet, he consistently produced very high quality code in terms of the code performing exactly to specs and without defects. I have another friend with whom I share many elements of taste - it is more natural for me to work with him. These are quality differences, yet in both cases we produce code that is of "high quality."

Bill Venners

Posts: 2248
Nickname: bv
Registered: Jan, 2002

Re: The Code Quality Myth Posted: Feb 25, 2005 11:43 AM
Reply to this message Reply
> Be patient. If I substituted nouns you could be talking
> about the U.S. auto industry in the 70s. And we know what
> happened when we didn't focus on quality.
>
> Watch India and China if you believe it won't be a problem
> for current software manufacturers.
>
> The lesson learned in manufacturing over the last 30 years
> is that extremely high quality bars make development
> faster. That is the lesson we have yet to learn as an
> industry.

I think developers have learned that lesson, at least the ones who have participated in this forum discussion. Everyone who has posted here has basically said the same thing in various ways. We seem to agree that the payback on code quality today is understandability and ease of change of that code tomorrow, which helps you move faster over the long haul. I think that management often understands this as well, but sometimes does not, and in the latter case it is we developers who should try and educate management about this return on investment for quality.

The main area of disagreement and misunderstanding seems to be in what quality and its payback means in a business context. I do imagine that even though quality is subjective, we might all agree that it isn't black or white. There isn't just good or bad code, for example, there is also OK code, excellent code, horrible code. Some who have expressed their opinion here seem to have a notion that some point on that quality spectrum (somewhere around good) is always worth aiming for, whereas Frank and I and a few others feel it depends on the business situation, that sometimes OK or even bad (once again, a subjective judgment) code is the right level of quality to produce.

To illustrate my point I can give you an example that involves both me and you: this website. I believe I had to reboot Tomcat twice yesterday, so some of you may have seen that, and experienced degrading response time before the reboot. It frustrates me that all of you have to put up with this problem, and I apologize, but let me also explain why it isn't solved yet. Artima has a scalability problem that I believe can be easily solved by upgrading hardware. I've been planning that upgrade for months, but each day so far other concerns have taken higher priority. For example, this week I spent several hours posting to my weblog and these forums about code quality and architecture, time that alternatively could have been spent shopping for and ordering parts for the new servers.

The business thinking went like this: I can provide value to Artima users by solving the annoying scalability problem, or I can provide value by posting some content to the the weblog and get the discussion going. I made the judgment that the return on investment of my time is better spent posting to the weblog and participating in the discussion. I think that's best for Artima, because it brings people in, more people sign up, it creates activity, builds momentum, because it provides a real value to the users, even though some of them will be frustrated by occasional slow response times or a 60 second rebooting message. And I think it is what users want too. Most users would prefer that I made that choice. If they didn't, they wouldn't come, and I would have made the other choice.

Uncle Bob mentioned he doesn't like to reboot his cell phone. I have many complaints about my cell phone too, but as Frank mentioned, both Uncle Bob and I continue to pay for our cell phone service. Why? Because despite its faults it gives us value that is worth the price and pain. So even though it really bothers me that users see occasionally slow response times and reboots from Artima, which I definitely view as low and, in the long term, unacceptable quality of service, I have accepted that lower quality for several months (i.e., in the short term), instead of spending time and money solving it, because of return on investment judgments. I will invest the time needed to fix it eventually, very soon in fact, but in the short term, I accept lower quality of service because it makes sense in this week's business context by allowing me to provide higher quality of content.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: The Code Quality Myth Posted: Feb 25, 2005 1:43 PM
Reply to this message Reply
> > Be patient. If I substituted nouns you could be
> talking
> > about the U.S. auto industry in the 70s. And we know
> what
> > happened when we didn't focus on quality.
> >
> > Watch India and China if you believe it won't be a
> problem
> > for current software manufacturers.
> >
> > The lesson learned in manufacturing over the last 30
> years
> > is that extremely high quality bars make development
> > faster. That is the lesson we have yet to learn as an
> > industry.
>
> I think developers have learned that lesson, at least the
> ones who have participated in this forum discussion.
> Everyone who has posted here has basically said the same
> thing in various ways. We seem to agree that the payback
> on code quality today is understandability and ease of
> change of that code tomorrow, which helps you move faster
> over the long haul. I think that management often
> understands this as well, but sometimes does not, and in
> the latter case it is we developers who should try and
> educate management about this return on investment for
> quality.

I hear you, but it seems that what you are saying and what Frank was saying in his original post are significantly different.

Kevin Lawrence

Posts: 13
Nickname: kevlaw
Registered: Feb, 2005

Re: The Code Quality Myth Posted: Feb 25, 2005 2:16 PM
Reply to this message Reply
> both Uncle Bob and I continue to pay for our cell phone service. Why? Because despite its faults it gives us value that is worth the price and pain.

See Uncle Bob's previous comment about US cars in the '70s.

That will change when someone figures out that

a) external quality has market value and
b) internal quality _improves_ time to market

Bill Venners

Posts: 2248
Nickname: bv
Registered: Jan, 2002

Re: The Code Quality Myth Posted: Feb 25, 2005 2:42 PM
Reply to this message Reply
> > I think developers have learned that lesson, at least
> the
> > ones who have participated in this forum discussion.
> > Everyone who has posted here has basically said the
> same
> > thing in various ways. We seem to agree that the
> payback
> > on code quality today is understandability and ease of
> > change of that code tomorrow, which helps you move
> faster
> > over the long haul. I think that management often
> > understands this as well, but sometimes does not, and
> in
> > the latter case it is we developers who should try and
> > educate management about this return on investment for
> > quality.
>
> I hear you, but it seems that what you are saying and what
> Frank was saying in his original post are significantly
> different.

My take on Frank's post is that he is not contradicting that quality code helps development teams move faster, which definitely has business value. Frank is observing that despite this, many successful businesses have apparently been built on poor quality code. I think Frank's point, which I agree with, is that although there is a strong correlation between code quality and the ability of a team to move fast, there is apparently a rather weak correlation between code quality and business success. The reason this makes sense to me is that although I can't move as fast with bad code, I can get bad code stable. And even to the extent I don't and the poor quality seeps through to the user experience, there are so many other factors that go into customer decisions besides the quality of the user experience that in many situations code quality can have very little to actually do with business success.

For example, ometimes businesses can very effectively compete primarily on time to market even with mediocre products. Way back in 1995 or 1996 I bought Java in 21 Days. It was full of errors, but I still bought it and found it quite valuable because it was the only Java book available. That publisher is apparently still in business, because the book is still in print.

People can compete on quality, but they can also compete on time-to-market, price, service, and any number of other things. I think the main way Artima competes with other blogging providers, for example, is the quality of the audience and the culture of quality discussions that exists here, not the quality of service or feature set of Artima Weblogs--certainly not the quality of the code.

My take on Frank's post is that the myth of code quality is not that code quality make you move fast, that's not myth. The myth is that code quality is strongly correlated to overall business success.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: The Code Quality Myth Posted: Feb 25, 2005 2:42 PM
Reply to this message Reply
> I agree that over time that gunk adds up, and that,
> eventually, the system can become monstrously expensive to
> maintain.
>
> But what are the options? Say, I have only $5000 in the
> bank. I have N customers willing to pay for this new
> feature. So what are my options? I can spend the money
> cleaning things up, and not implementing that feature. Or
> I can go ahead implementing that feature, knowing in the
> future I will have to deal with the consequences. Or, I
> can re-write the code from scratch. Or, I can just jump
> off a cliff. Which option would you choose? If you are a
> CEO of a company with fiduciary responsibility to your
> shareholders (or to your wife and kids), what option is
> most responsible? I can tell you that I would choose
> implementing and selling that feature. Maybe I would try
> to stay up all night for a couple of months and re-write
> the software, too...

I think the issue is really how the code got to the point that spending $X on clean up seems important relative to the feature addition. The cool thing is to amortize the cost of refactoring across development so that, well you could spend money making it prettier, but you know that the code is clean and supple enough to take on new features over the haul.

To me, the most dangerous time for a project is the market-seeking phase, because the corners that are cut then really come back to haunt. I also seriously doubt how much people save much time when they cut corners and work a little sloppy. I'd love to see numbers about on how long a typical programmer spends trying to understand code. My experience with teams is that it is a very very large component of the work when structure is poor.

Peter Hickman

Posts: 41
Nickname: peterhi
Registered: Mar, 2003

Re: The Code Quality Myth Posted: Feb 26, 2005 10:34 AM
Reply to this message Reply
What is missing here is that although the code is not the product it is a business asset without which the product cannot be made. The value of the asset could be measured by considering what would happen if you were buying the business.

The product sells well, that makes the company worth $X. You then look at the code and see that it is difficult to maintain, upgrade or extend. As a result the value of the business has now been decreased as these activities will require extra cash being spent beyond the purchase of the business.

Just as plumbing, wiring and glazing does not add to the value of a property bad plumbing, wiring and glazing will certainly lower the price.

Code is a business asset and software (based) companies seem to be negligent in care of their assets. I worked at a company that allowed the code to get so bad that despite the fact that the product sold well it had to embark on a whole new development because it had become too long and expensive to do what should have been simple changes to the existing code.

Then trying to pursuade the customers that they had to wait three years for the new system before any of the changes they wanted would be available was practically suicidal. The company shrank and managed to survive by sacking 50% of its developers and subletting office space.

It is no longer as big as it used to be and it was all due to the fact they their sole asset, the code, was never treated as more than a byproduct of the product creation.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: The Code Quality Myth Posted: Feb 26, 2005 3:12 PM
Reply to this message Reply
> To me, the most dangerous time for a project is the
> market-seeking phase, because the corners that are cut
> then really come back to haunt. I also seriously doubt
> how much people save much time when they cut corners and
> work a little sloppy. I'd love to see numbers about on
> how long a typical programmer spends trying to understand
> code. My experience with teams is that it is a very very
> large component of the work when structure is poor.

Yes, I definitely agree with that. My intiution is that understanding a given piece of code is largely dependent on the developer, and also how much extra context is needed (context not readily available from the few pages of code the developer can keep in his head at a time). Sometimes high levels of abstraction, for instance, require more effort at understanding a given class or method because not all information for that understanding is readily available from the given text. (Kind of like reading T.S. Eliot)

For instance, the other day, a customer reported a bug in our main product. That bug was triggered at a particular edge case. So what I ended up doing was to add a snippet of code that checked for that edge case: if (edgeCase) {..} else { //normal execution }. Now, I would normally consider this a hack, and I know deep down that I will need to refactor this into something more abstract. But, on second thought, perhaps not: Anyone reading that snippet of code for the first time will understand why its there and what it does there. If I moved that changed in logic somewhere else, it would be harder to understand the code. Of course, over time, these kind of easy-to-understand local "edits" add up, and can easily create a mess. So, at that point, these things require refactoring.

So, I think, what happens is that short term we must live with these ugly little hacks to expedite moving the business forward. Periodically, they require refactoring, which then contributes to an architecture or design - not an upfront design, but design that sort of emerges. I think the key, though is to then come back and look at that architecture from the viewpoint of someone coming to that codebase for the first time - to ensure that that design still contributes to the understanding of the code.

Bill Venners

Posts: 2248
Nickname: bv
Registered: Jan, 2002

Re: The Code Quality Myth Posted: Feb 26, 2005 3:54 PM
Reply to this message Reply
> I hear you, but it seems that what you are saying and what
> Frank was saying in his original post are significantly
> different.

On second thought, I just reread Frank's post and may see your point. Frank writes, "When we spend time to make our code high quality, we justify that effort by saying that the work would provide some business benefit down the road. The trouble is, code quality, by itself, seldom results in any measurable business return on investment..."

I do believe there is a business return on investment for quality code that manifests itself as developer productivity and morale in the future. I am certainly happier when I get to work on quality code with a team that cares about quality, and that by itself may help me be more productive and less likely to quit my job and go elsewhere. That is value for the business: the programmers are faster and happier.

Frank didn't say "return on investment," though, he said "measurable return on investment." Programmer productivity and morale are not so easy to measure, and it is not so easy to figure out how that might have affected the bottom line in the previous quarter or year. And you certainly can't measure something that hasn't happened yet. When planning your current investments you have to make judgements of what value investing in code quality now will get you down the road, and use that to decide how good is good enough.

I have a story somewhat similar to Peter Hickman's story of a codebase that got so bad it became a business crisis. Peter said they were forced to start over from scratch. Where I worked the software was for a machine that was planned to be obsoleted in a few years. They were designing a new generation of machines, and in the new generation the old software wouldn't work anyway, so they were writing the software for the new generation pretty much from scratch.

The code quality of the software that ran the current generation of machines, the ones being sold at the time, was very poor. Our favorite thing to point to at the time as an example of the poor quality was an 11-page while loop, which was critical part of the functionality of the software. The poor code quality didn't just frustrate us as programmers, it also seeped through to frustrate users. In fact, the software crashed so much it was starting to hinder customer acceptance of these machines (each of which cost about 1 million dollars). So the company decided to create a "task force" to clean up the software. Before the task force there were about 3 or 4 programmers working on the code, and they brought in another 8 or so, plus a manager to lead the task force full time. We worked about three months if I remember right, and were asked to come in on the weekends.

So this company invested a lot in improving code quality because there was a business crisis. Not only were they paying about 12 developers full time, 8 of them had been pulled from other projects that were now not making any progress. But here's the thing: Our job was just to get the software stable enough so that it wasn't hindering acceptance anymore, and so that the problem wouldn't arise again in the next few years, after which the product would be obsoleted. And we did that, but afterwords, that 11-page while loop was still an 11-page while loop. Where before I would have given the code an F, after the task force maybe it would get a D. That D code was deemed good enough to meet the business need.

Some may argue that if the code quality had been high from the start, then the crisis would never have arisen. That's true, but we can't go back in time and B, C, D, and F code exists today all over the place. This organization did seem to learn that they needed to invest in quality, because they spent a lot of money trying to do a better job with the new generation of software. They adopted a formal methodology: Yourdon/Constantine. We were all sent to classes to learn it. They bought everyone an expensive Sun Workstation and a $25,000 a seat CASE tool. That team spent months and months drawing bubble charts, then structure charts, before finally starting in on the code. I don't know how the code came out, because I left that company, but I could see that management had decided that quality code was worth something to the business.

After the task force, I still worked on that D codebase for a while before moving to a different project. And we basically accepted D quality, because it was good enough in the business context. If we had an enhancement to make in the 11-page while loop module, we didn't bother taking the time to clean up that while loop, we just accepted it and made the change as best we could. I do believe that had the company continued the task force a few more months that we could get the code to C or eventually B. And there would be a return in terms of more productive and happier programmers, but it was deemed a better return on investment would likely be gained by letting two thirds of that team go to work on the new generation of software.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: The Code Quality Myth Posted: Feb 26, 2005 10:32 PM
Reply to this message Reply
> But what are the options?

You always have the option of doing a good job.

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