By page 19 (and 13 pages of forewords) we learned that there are two opposite views of how software should be developed: disciplined and flexible, and that the author will in the end show us that the middle way is the best.
Author's theory about software practice includes these issues:
- Discipline vs. flexibility
- Formal methods vs. heuristics
- Optimizing vs. satisficing (sic!)
- Quantitative vs. qualitative
- Process vs. product
- Intellectual vs. clerical tasks
On page 268 there is a good list of what academic research should be focusing on, two of which seem especially worthy:
- issues contrary to commercial interests,
- unsolved problems.
I think that definition of standards with sample implementations might fall into the "contrary to commercial interests" category. This might prevent the "design by committee" problems that we see in CORBA and IATA CUSS standards.
Chapter 9 contains an interesting discussion of "fun" in software development. The author references a paper by Bruce Blum, who lists the fun/tedium ratio for different phases of SDLC:
- "selling the concept" phase - pure problem solving/analysis phase: 100% fun - 0% tedium
- writing down requirements: 50-50
- top-level design: 40-60
- detailed design: 33-67
- programming: 75-25
- testing: 33-67
- maintenance: 0-100
Chapter 9.3 mentions another interesting idea for creating projects with higher ratio of fun - the "incremental consensus" technique by Jerry Weinberg: begin with 2 people who want to work in a mutually pleasing manner and succeed on a project, then grow the team in increments of 1 and only when the candidate gets everyone's acceptance.
Chapter 13 lists ideas on how organizations can become more creative:
- support open sharing of information
- support risk-taking behaviors
- create group diversity
- create highly participative culture
- create "slack resources"
Chapter 14 lists traits of creative people.
Chapter 15 shows that computer tools can decrease creativity in problem solving.
Chapter 16 explains creativity paradoxes:
- The more you know about the problem domain, the less creative your solutions are.
- To come up with creative solutions, you must know how others solved it.
Chapter 17 shows that software life cycle is just an implementation of a universal problem solving algorithm:
- Identify a problem.
- Define the requirements of the problem.
- Design a solution to the problem.
- Implement the design.
- Test the implementation.
- Use the implemented product.
Summary:
What I am missing in this book is the word "pragmatic". It is a simple, elegant, and "to the point" summary of the approach that Robert L. Glass postulates to use for software development.
No comments:
Post a Comment