> 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.
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
[
«
|
1234
]
Previous Topic
