8 - Calling the Shot
The effort of building large systems is non-linear, even if there is no extra communication needed.
Projects often take double the initial estimated time to complete. People often only work 50% of the time on development (the other is short unrelated jobs, meetings, paperwork, sickness, personal time etc.)
I think this may be a little higher, maybe 70%, but some roles i a project are more prone to communication disturbances
Productivity seems constant in terms of elementary statements. So, high level languages are good.
The higher the better? Where is Perl?
9 - Ten Pounds in a Five-Pound Sack
For an given function, the more space, the faster. This is true over an amazingly large range of problems.
Representation is the essence of programming.
Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables and I won't usually need your flowcharts; they'll be obvious.
10 - The Documentary Hypothesis
Existance of a budget forces technical decisions that otherwise would be avoided.
Writing is essential. The act of writing turns out to require hundreds of mini-decisions.
The fundamental job of the manager is to keep everyone going in the same direction. This requires communication rather than decision-making. Documents ease that job.
11 - Plan to Throw One Away
The actual need, and the perception of that need, will change as programs are built, tested, and used.
Plan the system for change.
The cost of maintenance is typically 40% or more of the development cost.
Fixing a defect has a high chance of introducing another. So the whole process is two steps forward and one step back.
Enter regression testing.
Maintenance requires more testing than development.
Code with no side effects, and fewer interfaces, using fewer people, can lead to fewer bugs.
12 - Sharp Tools
Tools are necessary. Build them if needed.
13 - The Whole and the Parts
System tests are unexpectedly hard.
Use debugged and tested components.
Don't leave documented bugs for later, you don't know their effect until they're fixed.
Add one component at a time.
14 - Hatching a Catasrophe
How does a project get to be a year late? One day at a time.
Have a schedule.
Milestones must be knife-sharp, concrete, definable events. It's finished when it's 100% finished, no sooner.
Estimates don't change before the project. During the activity, over-estimates come down. During the activity, under-estimates don't change until two or three weeks until scheduled completion.
Dependencies are vital to track.
15 - The Other Face
Users need a prose description of the program. Most documentation gives to little overview.
Flow-charts suck (unless maybe if you do assembler).
Write self-documenting code.
16 - No Silver Bullet - Essence and Accident in Software Engineering
Re-use what is already coded. Prototype. Grow software organically. Encourage good designers.
The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions.
Complexity. Software entities are more complex for their size than perhaps any other human constuct, because no two parts are alike. If they are, we make them into one.
The complexity of software is an essential property. Hence descriptions of a software entity that abstract away its complexity often abstract away its essence.
From the complexity comes the difficulty of enumerating, much less understanding, all the possible states of a program.
Conformity. Much of the complexity comes from outside, real-life, sources.
Changeability. A software entity is constantly subject to pressure for change. All successful software gets changed.
The software in a system embodies its function, and the function is the part that most feels the pressures of change.
Invisibility.
High-level languages frees a program from much of it's accidental complexity.
The hard thing about building software is deciding what to say, not saying it. The clients don't know what they want.
Great design come from great designers. Software construction is a creative process.
17 - "No Silver Bullet" Refired
Focus on quality and productivity will follow.
Programmers have always reused their own handiwork.
