A (few) words to the wise

Here are the conclusions (categorized, mildly edited & slightly extended) from Boehm's retrospective of the past 50 years of software development.

Some of these are contradictory. Such is the way of wisdom.

Skepticism and Critical Thinking:

• Be self-aware. Know your own strengths and weaknesses, and how to manage them.
• Don’t believe everything you read. Be wary of the downslope of the Gartner "hype-cycle" roller-coaster.
• Be skeptical about silver bullets, and one-size-fits-all solutions.
• Avoid falling in love with your slogans. YAGNI (you aren’t going to need it) is not always true.

Total Commitment to Quality:

• Avoid cowboy programming. The last-minute all-nighter frequently doesn’t work, and the patches get ugly fast.
• Eliminate errors early. Even better, prevent them in the future via root cause analysis.
• Be quick, but don’t hurry. Overambitious early milestones usually result in incomplete and incompatible specifications and lots of rework.

Flexibility and Craftsmanship:

• Avoid using a rigorous sequential process. The world is getting too tangeable and unpredictable for this, and it’s usually slower.
• Avoid Top-down development and reductionism. COTS, reuse, IKIWISI, rapid changes and emergent requirements make this increasingly unrealistic for most applications.
• Look before you leap. Premature commitments can be disastrous (Marry in haste; repent at leisure – when any leisure is available).
• Keep your reach within your grasp. Some systems of systems may just be too big and complex.

Clarity and Communication:

• Determine the system’s purpose. Without a clear shared vision, you’re likely to get chaos and disappointment. Goal-question-metric is another version of this.
• Make software useful to people. This is the other part of the definition of “engineering.”
• Consider and satisfice all of the stakeholders’ value propositions. If success-critical stakeholders are neglected or exploited, they will generally counterattack or refuse to participate, making everyone a loser.
• Have an exit strategy. Manage expectations, so that if things go wrong, there’s an acceptable fallback.

The Skill and The Discipline:

• Respect software’s differences. You can’t speed up its development indefinitely. Since it’s invisible, you need to find good ways to make it visible and meaningful to different stakeholders.
• What’s good for products is good for process, including architecture, reusability, composability, and adaptability.
• If change is rapid, adaptability trumps repeatability.
• Don’t neglect the sciences. This is the first part of the definition of “engineering”. It should not include just mathematics and computer science, but also behavioral sciences, economics, and management science. It should also include using the scientific method to learn through experience.

Performance:

• Time is money. People generally invest in software to get a positive return. The sooner the software is fielded, the sooner the returns come – if it has satisfactory quality.
• These are many roads to increased productivity, including staffing, training, tools, reuse, process improvement, prototyping, and others.
• Think outside the box. Repetitive engineering would never have created the Arpanet or Engelbart’s mouse-and-windows GUI. Have some fun prototyping; it’s generally low-risk and frequently high reward.