Enterprise Architecture: From Incite comes Insight...: Industry Analysts, Ruby and the Fallacy of Productivity (Part Two)

Tuesday, April 11, 2006

Industry Analysts, Ruby and the Fallacy of Productivity (Part Two)

Hype is the plague on the house of software. I wonder if any of the industry analysts and the folks in the Ruby community that promote "productivity" have ever read Robert Glass book entitled: Facts and Fallacies of Software Engineering. If not, they should...

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.

People

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.

Estimation

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’.

Reuse

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.

Complexity

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.

Requirements

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.

Design

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.

Coding

Fact: Designer ‘primitives’ rarely match programmer ‘primitives’.
Fact: COBOL is bad. All the others for business applications are much worse.

Error Removal

Fact: The most time-consuming phase of the software life cycle.

Testing

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.

Maintenance

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.

Quality

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.

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.

Efficiency

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.

Research