The Rules of Engineering
Found on a wall in a mechanical engineering shop. But many of these
dicta apply just as well to software engineering.
- Engineering is done with numbers. Analysis without numbers
is, at best, only an opinion.
- Design is an iterative process. The necessary number of iterations
is one more than the number you have currently done. This is true at
any point in time.
- Everything is linear if plotted log-log with a fat magic marker.
- When in doubt, estimate. In an emergency, guess. But be sure to
go back and clean up the mess when real numbers come along.
- The odds are greatly against your being immensely smarter than
everyone else in the field. If your analysis says your terminal
velocity is twice the speed of light, the chances are better that you've
screwed up than that you've invented warp drive.
- At the start of any design effort, the person who most wants to
be team leader is least likely to be capable of it.
- In nature, the optimum is almost always in the middle somewhere.
Distrust assertions that the optimum is at an extreme point.
- Not having all the information you need is never a satisfactory
excuse for not starting the analysis.
- Your best efforts will inevitably wind up being useless in the
final design. Learn to live with the disappointment.
- Sometimes, the fastest way to get to the end is to throw everything
out and start over.
- There is never a single right solution. But there are always multiple
- Design is based on requirements. There's no justification for designing
something one bit "better" than the requirements dictate.
- "Better" is the enemy of "good".
- The ability to improve a design occurs primarily at the interfaces.
This is also the prime location for screwing it up.
- The previous people who did a similar analysis did not have
a direct pipeline to the wisdom of the ages. There is therefore no reason
to believe their analysis over yours. There is especially no reason to
present their analysis as yours.
- The fact that an analysis appears in print has no relationship
to the likelihood of its being correct.
- Past experience is excellent for providing a reality check.
On the other hand, too much reality can doom an otherwise worthwhile design.
- A bad design with a good presentation is doomed eventually.
A good design with a bad presentation is doomed immediately.
- Half of everything you hear in a classroom is crap. Education is
figuring out which half is which.
- When in doubt, document. Documentation requirements will reach
a maximum shortly after the termination of the project.
- It's called a "Work Breakdown Structure" because the Work remaining
will grow until you have a Breakdown, unless you enforce some Structure
- The first 90 percent of the project takes 90 percent of the allotted time.
The last 10 percent of the project takes the other 90 percent.