Book: Effective Requirements Practices , Addison-Wesley, 2001, ISBN 0201709120

• We know from industry experience that customers don't know their "real requirements" (even though they may have spent a lot of time defining them and believe they know them). Suppliers and system developers don't know them either. Identifying the real requirements requires an interactive requirements process. (p xxv).
• Manage by fact. (p 41).
• Industry sources indicate that by taking the effort to document why each requirement is needed, as many as half of the "requirements" can be eliminated. (p 84).
• No requirement should be put into the specification until its rationale is well understood. (p 84).
• It's important to train requirements engineers and developers not to make assumptions, not to make requirements decisions and not to gold plate. (p 91).
• I recommend that concurrent with requirements elaboration, we involve a small team of designers to review requirements for the implementation impacts. (p135. Citing systems architect Mike Reaves).
• The fish isn't sick . . . The water is dirty. (p165. Citing Steven Gaffney).
• Not having all members of the technical team at the same physical location is a significant risk that complicates communication and coordination extraordinarily. (p174).

Book: The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition
Addison-Wesley, 1975 ISBN 0201006502, reprint 1995 ISBN 0201835959

• Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is the most difficult part of learning to program.
• Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.
• All programmers are optimists.
• Adding people to a late project makes it later (Brooks' Law, 1975).
• Programming projects took about twice the expected time. Research showed that half of the time was used for activities other than the project
• Estimates make an unrealistic assumption about the number of technical work hours per man-year.
• Productivity seems constant in terms of elementary statements (assembler, C, C++).
• Writing down decisions is essential. Only when one writes, do the gaps appear, and the inconsistencies protrude.
• Plan to throw one away; you will, anyhow. Or did you promise to deliver the throwaway to the customer?
• Change is a way of life, rather than an annoying exception.
• The fundamental problem with program maintenance is that fixing a defect has a substantial (20~50%) change of introducing another.
• All repairs tend to destroy structure, enlarge the entropy, and disorder in the system.
• Many failures concern exactly the aspect that were never quite specified.
• How does a project get to be a year late? One day at the time.
• Day by day slippage is harder to recognise, harder to prevent, harder to make-up.
• Coding is "90% finished", half of the time. Debugging is "99% complete" most of the time. Concrete milestones are 100% events.
• A schedule slips a day; so what? It's only a day... One must get excited about a one day slip. Slips are elements of catastrophe.

Dijkstra called himself the first programmer in The Netherlands (since 1952).

Paper: Programming Considered as a Human Activity, 1965
in Classics in Software Engineering , Yourdon Press, 1979. ISBN 0917072146

• Emphasis on program correctness and quality: concept of elegance. Elegance is associated with luxury, so the tacit assumption is that it costs to be elegant. However, it pays to be elegant.
• When computers produce results, why do we trust them, if we do so? How can we prove that the results will always be correct? The convincing power of the results is greatly dependent on the clarity of the program
• Divide et impera. I have only a small head and must live with it. Computers are getting faster and more powerful, human beings aren't.

Lecture: The Humble Programmer, 1972
in Classics in Software Engineering , Yourdon Press, 1979. ISBN 0917072146

• Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper.
• If you want more effective programmers, you will discover that they should not waste their time debugging - they should not introduce the bugs to start with.
• We should confine ourselves to intellectually manageable programs.
• We must not forget that it is not our business to make programs; it is our business to design classes of computations that will display a desired behaviour.
• It is a usual technique to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.
• The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
• The question: "Can you code this in less symbols?" or, "Guess what it does?"- as if this were of any conceptual relevance!
• As long as machines were the largest item in the budget, the programming profession could get away with its clumsy techniques.

Book: Classics in Software Engineering , Yourdon Press, 1979. ISBN 0917072146

Requirements engineering

• Software requirements engineering is the discipline for developing a complete, consistent, unambiguous specification, to be understood by all parties, describing what the software will do, for whom, and why.
• The extreme importance is derived from:
  • It is easy to delay or avoid doing thoroughly
  • Deficiencies in it are very difficult and expensive to correct later
• If there are no complete requirement specifications:
  • Top-down design is impossible, because there is no well specified top
  • Testing is impossible, because there is nothing to test against
  • The user is frozen out, because there is no statement what is being produced for him; he may not even be defined
  • Management is out of control, because there is not clear statement of what the project team is producing.
• The techniques used for determining software requirements are generally an ad hoc manual blend of systems analysis principles and common sense. (These are the good ones; the poor ones are based on ad-hoc manual blends of politics, preconceptions and pure salesmanship).
• Requirements specifications abound with terms such as "suitable", "real-time", "flexible", "user-friendly", "optimum", "reliable". These terms have no value.

Software design

• Software design defines how the requirements should be realised.
• Research indicates that a lot more than half of all errors found are requirements and design errors. These are errors of which the fix requires a fix in the requirements or design specifications.
• There is little organised knowledge of what a software designer does, how he does it, or what makes a good software designer.

Software testing

• Surprisingly often, software testing and reliability activities are still not considered until the code has been run the first time and found not to work.
• In general, the high cost of testing (some 50% of the development effort) is due to the high cost of reworking the code at this stage and to the wasted effort resulting from the lack of an advance test plan to efficiently guide testing activities.
• Most testing is a tedious manual process, which is error-prone in itself.
• For comparison of error data one should establish error-classes to document (or count) errors.
• We should continue to collect and analyse data on how, when, where and why people make software errors in order to find means to avoid people making these errors.

Software management

• There are more opportunities for improving software productivity and quality in the area of management than anywhere else.
• Software project success or failure is most often caused by software management.
• Management problems:
  • Poor planning
    Leads to large amounts of wasted effort because of tasks being unnecessarily performed, overdone, poorly synchronised or poorly interfaced
  • Poor control
    Even a good plan is useless when it is not kept up-to-date and used to manage the project
  • Poor resource estimation
    Without a firm idea of how much time and effort a task should take, the manager is in a poor position to exercise control
  • Unsuitable management personnel
    Software personnel tend to respond to problem situations as designers rather than as managers
  • Poor accountability structure
    Projects are generally organised and run with diffuse delineation of responsibilities.
  • Inappropriate success criteria
    Minimising development costs and schedules will generally yield a hard-to-maintain product.

The "average coder" of software: 2 years college-level education, 2 years software experience, familiarity with 2 programming languages and 2 applications, generally introverted, sloppy, inflexible, "in over its head" and undermanaged. This has strong implications for effective software engineering technology which, like effective software, must be well-matched to the people who must use it.

Book: Classics in Software Engineering , Yourdon Press, 1979. ISBN 0917072146

• Early understanding is always imperfect. But a careful and precise declaration of an imperfect understanding is the best tool for refinement and correction.
• The human mind is an iterative processor, it never does anything right the first time. What it does well is to make improvements on every iteration.
• The idea of making a flawed early version and then refining to make it right is a very old one. It is called engineering.
• The classical specification describes what the computer does: the processing inside and the input and output data transfer. It almost never specifies anything that happens outside the man-machine boundary.
• A parameter that is likely to be changed ought to be defined in one place and one place only.
• Freezing specifications is a dream. It cannot be forestalled; it can only be ignored.

Paper: Programming style: Examples and counterexamples, 1974
in Classics in Software Engineering , Yourdon Press, 1979. ISBN 0917072146

• Robustness:
  • The program should work; not just for every case, but all the time.
  • Garbage in - garbage out is not a law of nature, it is the result of a lazy programmer.
  • Special cases should work.
  • Check also the boundaries. For instance, does a sorting program correctly sort a list of just one element? And of zero elements? Does a table-lookup routine work when the table is empty? What if sqrt(0)? Inversion of matrix with 1 element?
• Efficiency:
  • Until we have a working piece of code, we don't know where it spends its time. And until we know that, it is foolish to change "for efficiency".
  • Write the whole program clearly. If then it turns out to be too slow or too big, change to a better algorithm. Since you wrote it clearly, change will be easy.
  • Improve only the critical parts. Leave the rest alone.

Paper: Chief Programmer Teams, 1973
in Classics in Software Engineering , Yourdon Press, 1979. ISBN 0917072146

• Including all overhead, five to ten debugged instructions are coded per man-day on a large programming project. The coding time for these instructions cannot exceed more than a few minutes. What do programmers do with the remaining time of the working day? They debug.
• It is the thinking errors, more than the coding errors, which limit the programming productivity.

Paper: Debugging the Development Process, 1994
in Debugging the Development Process : Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
Microsoft Press 1994. ISBN 1556156502

• Don't waste developers time on work that does not improve the product.
• Don't take me too literally...
• [Think:] What am I ultimately trying to accomplish?
• Establish detailed project goals to prevent wasting time on inappropriate tasks.
• Don't fix bugs later; fix them now.
• Strategies for writing bug-free code:
  • How could I have prevented this bug?
  • How could I easily have prevented this bug?
• Strategies for preventing problems:
  • How can I avoid this problem in the future?
  • How can I learn from this mistake/experience?
• Don't present strategies as ironclad rules; present strategies as guidelines to be followed most of the time.
• Don't play the "Maybe this is the problem" game.
• Don't waste time working on the wrong problem. Always determine what the real problem is before you try to make a fix.
• People often ask for something other than what they really need. Always determine what they are trying to accomplish before dealing with any request.
• Never commit to dates you know you cannot meet. You will hurt everybody involved. Learn to say No.
• Don't let wanting to please everybody jeopardise your project. Use your goals to guide your decisions.
• Anytime corporate policy has somebody writing a report that nobody will read, corporate policy is wrong.
• Be sure that every report you ask for is worth the time it takes for the writer to prepare it.
• If you do postmortem reports, be sure to include a detailed plan that describes how you plan to take care of each known problem so that it does not come up in the next project. (Problem; Proposed Solution)
• Will the results of this meeting be important enough to warrant interrupting the work of people who will have to attend it?
• Before calling a meeting, be sure you know exactly what you want to achieve and what you need to achieve it. Then make sure you do achieve it.
• Never allow team members to jeopardise the product in the attempt to hit what might be, after all, an arbitrary deadline.
• Most deadlines are arbitrary.
• Make sure each team member learns one new significant skill at least every two months.
• Take immediate action the moment you realise that an area needs improvement.
• Be sure programmers understand that writing bug-free code is so difficult that they cannot afford not to use every means to detect and prevent bugs.
• Watch out for the "it's too much work" reaction. Train programmers to first consider whether the task makes sense and whether it matches up with the project goals and priorities.
• When somebody says that something can't be done, he or she is usually wrong.
• Don't ship substandard features. Postpone them until you can implement them properly.
• If a ship is sinking, search for the leaks.
• If a project is slipping, something is wrong. Don't ignore the causes and demand long hours of the team members. Find and fix the problems.
• Long hours hurt productivity
• Stress the importance of thinking hard, not working hard.

Book: Debugging the Development Process : Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
Microsoft Press, 1996. ISBN 1556159005

• Doing a few things right does not guarantee Rapid Development. You also have to avoid doing anything wrong.