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 ]
Scott Bain

Posts: 1
Nickname: slbain
Registered: Mar, 2006

Re: The Code Quality Myth Posted: Mar 16, 2006 4:27 PM
Reply to this message Reply
Advertisement
> What a shame. The word "maintainability" doesn't appear
> anywhere in the author's article.

I think you're closer to the mark here.

What do we mean by "quality"? If you were to ask this question in 1982, I think the answer would have been very different then due to the forces present in technology and the way it effected commerce at the time.

1) Computers were more expensive than developers
2) Computers were reletively slow
3) Storage and memory were very costly
4) Software was in relatively fewer places
5) Software effected relatively fewer business/human processes

Every one of these forces is different in 2006.

1) Developer time is a larger cost than hardware
2) Computers are orders of magnitude faster
3) Storage and memory are cheap
4) Software is everywhere
5) Software effects virtually all business/human processes, and those it does not, it soon will.

So, "good software" in the past could easily have been defined as "fast and small", and if it was too difficult to maintain, well, it could be re-written. Developers were cheap, and there was not nearly as much software to worry about in the first place.

"Good software today" is, I submit, changeable without discarding it, or as you have put it, "maintainability" is a much more considerable virtue than it was in the past.

Frank has a point, but I think it has to be cast as a business decition along these lines:

If we decide not to spend what is needed to ensure that our code can be efficiently changed to meet customer needs, then we must consider this a debt incurred by the organization. As with any debt, it must be serviced, and the "interest on the debt" means that fixing the problems later will always be more expensive than fixing them now would be. This is true for good design, or refactoring.

However, even if we accept that good code is more expensive to produce (which I actually doubt, but let's let the point have its moment), I would at least suggest that the business must consider this expense to be an investment, since future enhancements will be cheaper to achieve than they would otherwise be, and thus the investment will pay off in this way.

Debt and investment are concepts a business understands. I think most businesspeople would prefer to be invested in a valueable asset than servicing a debt, if they had the ability to choose.

83011

Posts: 1
Nickname: 83011
Registered: Jul, 2012

Re: The Code Quality Myth Posted: Jul 16, 2012 6:12 PM
Reply to this message Reply
As a professional developer and past MIS boss I totally agree with Robert C. Martin's comments ... quality does matter.

Missing a critical deadline or blowing a show in front of investors can ruin your company. Missing a requirement in a mission ciritical system can cost lives. So if I am responsible than I want to reduce risk.

My experience is that well designed, coded and tested systems allow for low-risk modifications and enhancements.

Quality code means any developer can work or any part of the system with good results. So I can reassign members as needed.

If my teams have consensus about what good design and code are, it means peer reviews work, it means estimates work, it means training new people is faster and easier, it means programmers will raise quality issue, discuss and correct them.

And most of all I have observed the teams feel good about their work...

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