Tuesday, April 11, 2006
Industry Analysts, Ruby and the Fallacy of Productivity (Part Two)
Hopefully neither industry analysts nor the Ruby community will get too torqued in that I decided to list facts when they could only respond with their own perspective. The list below is essentially the outline of the book. Each fact and fallacy is explained in its own section, with its controversial aspects both acknowledged and addressed, and ample references are supplied supporting each assertion.
- Fact: The most important factor in software work is the quality of the programmers.
- Fact: The best programmers are up to 28 times better than the worst programmers.
- Fact: Adding people to a late project makes it later.
- Fact: The working environment has a profound impact on productivity and quality.
Tools and Methodologies
- Fact: Hype is the plague on the house of software.
- Fact: New tools and techniques cause an initial loss of productivity and quality.
- Fact: Software developers seldom really use tools.
- Fact: A common cause of runaway projects is poor estimation.
- Fact: Software estimation usually occurs at the wrong time and is done by the wrong people.
- Fact: Software estimates are rarely corrected.
- Fact: We do live and die by software estimates, despite their badness.
- Fact: There is a disconnect between management and programmers.
- Fact: Feasibility studies almost always answer ‘yes’.
- Fact: Reuse in the small is well-solved.
- Fact: Reuse in the large is mostly unsolved.
- Fact: Reuse in the large works best for families of related systems.
- Fact: Reusable components cost three times as much to build and should be tested in at least three settings.
- Fact: Modification of reused code is particularly error-prone.
- Fact: Design pattern reuse is a good idea.
- Fact: For each 25% increase in problem complexity, there is a 100% increase in solution complexity.
- Fact: 80% of software work is intellectual. Some is creative. Little is clerical.
- Fact: The second common cause of runaway projects is requirements instability.
- Fact: Requirements errors are most expensive to fix during production.
- Fact: Missing requirements are very hard to fix.
- Fact: Explicit requirements ‘explode’ as the design evolves.
- Fact: Multiple design solutions usually exist.
- Fact: Design is complex and iterative. Initial designs are usually wrong and certainly non-optimal.
- Fact: Designer ‘primitives’ rarely match programmer ‘primitives’.
- Fact: COBOL is bad. All the others for business applications are much worse.
- Fact: The most time-consuming phase of the software life cycle.
- Fact: Aim for 55-60% branch coverage.
- Fact: 100% branch coverage is far from enough.
- Fact: Test tools are essential.
- Fact: Test automation rarely is. Most tests cannot be automated.
- Fact: Your debug code is an important supplement to testing tools.
Reviews and Inspection
- Fact: Rigorous inspections can catch 90% of the errors.
- Fact: Rigorous inspections should not replace testing.
- Fact: Postdelivery reviews are important and seldom performed.
- Fact: Reviews are both technical and sociological. Accommodate both.
- Fact: Maintenance is the most important life cycle phase with 40-80% of the cost.
- Fact: Enhancements make up about 60% of the maintenance cost.
- Fact: Maintenance is a solution, not a problem.
- Fact: Understanding the existing product is the most difficult maintenance task.
- Fact: Better methods lead to more maintenance.
- Fact: Quality is a number of attributes: Portability, reliability, efficiency, usability, testability, understandability, and modifiability.
- Fact: Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.
- Fact: There are common errors that most programmers make.
- Fact: Errors tend to cluster.
- Fact: There is no single best approach to software error removal.
- Fact: There are always residual errors. The goal is to minimize or eliminate severe errors.
- Fact: Efficiency stems from good design, not good coding.
- Fact: High-order language code can be about 90% as efficient at hand-coded assembly language code.
- Fact: Size and time optimization trade off.
- Fact: Many researchers advocate rather than investigate
- You can’t manage what you can’t measure.
- You can manage quality into a software product.
- Programming can and should be egoless.
- Tools and techniques: one size fits all.
- Software needs more methodologies.
- To estimate cost and schedule, first estimate lines of code.
Life Cycle Fallacies
- Random test input is a good way to optimize testing.
- “Given enough eyeballs, all bugs are shallow.”
- To predict future costs, look at past cost data.
- You teach people how to program by showing them how to write programs.
Links to this post: