A View of 20th and 21st Century Software Engineering

I've been digging pretty deep into the Software Engineering literature to prepare a new course I am developing and came across this. It's always fun to have a top-10 list even in the driest of topics, so here is Barry Boehm's "Timeless Principles (+) and Aging Practices (-) of Software Engineering!

4.1 TimelessPrinciplesandAgingPractices

For each decade, I’ve tried to identify two timeless principles headed by plus signs; and one aging practice, headed by a minus sign.

From the 1950’s

  • + 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.

  • + Look before you leap. Premature commitments can be disastrous (Marry in haste; repent at leisure – when any leisure is available).

  • − Avoid using a rigorous sequential process. The world is getting too tangeable and unpredictable for this, and it’s usually slower.

From the 1960’s

  • + 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.

  • + 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.

  • − Avoid cowboy programming. The last-minute all-nighter frequently doesn’t work, and the patches get ugly fast.

From the 1970’s

  • + Eliminate errors early. Even better, prevent them in the future via root cause analysis.

  • + 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.

  • − Avoid Top-down development and reductionism. COTS, reuse, IKIWISI, rapid changes and emergent requirements make this increasingly unrealistic for most applications.

From the 1980’s

  • + These are many roads to increased productivity, including staffing, training, tools, reuse, process improvement, prototyping, and others.

  • + What’s good for products is good for process, including architecture, reusability, composability, and adaptability.

  • − Be skeptical about silver bullets, and one-size-fits-all solutions.

From the 1990’s

  • + 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.

  • + Make software useful to people. This is the other part of the definition of “engineering.”

  • − Be quick, but don’t hurry. Overambitious early milestones usually result in incomplete and incompatible specifications and lots of rework.

From the 2000s

  • + If change is rapid, adaptability trumps repeatability.

  • + 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.

  • − Avoid falling in love with your slogans. YAGNI (you aren’t going to need it) is not always true.

For the 2010’s

  • + Keep your reach within your grasp. Some systems of systems may just be too big and complex.

  • + Have an exit strategy. Manage expectations, so that if things go wrong, there’s an acceptable fallback.

  • − Don’t believe everything you read. Take a look at the downslope of the Gartner rollercoaster in Figure 10.