Workshop: No Silver Bullet

OOPSLA 2007, Montreal
October 22, 2007

Workshop Final Report

There were six main issues discussed during the session:

Issue 1: Reflection on Brooks' Promising Attacks

There are four specific "promising attacks on the conceptual essence" that are listed in the original Brooks article:

The workshop participants think that all four of these promising attacks are still promising today -- and at least one of them is widely used: Buy versus build.

Some reflections on how these attacks are used today:

Do we have any new promising attacks to add to what Brooks wrote 20 years ago? Yes:

Issue 2: What are the ways to deal with complexity?

Can we really "avoid" complexity? Or if we try to remove it in one place, it will just pop up somewhere else?

One reality: the world is complex. A lot of requirements come across our desks that are based on things that seem very arbitrary -- government regulations, user fashions, and so on. Can we succeed at simplifying things, or at least cope with complexity?

There are four increasingly mature ways to deal with complexity:

Workshop participants thing that the last two (filter or embrace) are the only practical ways to deal with complexity. The other two will cause all sorts of problems.

Issue 3: Candidates for "what is the werewolf?"

This question raised a lot of discussion in the workshop. There are three major answers:

Complexity is the natural place to start the blame: in software development we are building systems that are more complex than bridges, refineries, automobiles, and most other products of engineering.

People comes next -- because we are looking for why all of that complexity is present...

There will be even more people problems in the future, because there is a decline in CS enrollment in universities today -- so there may be a decline in the number of software professionals.

But... we shouldn't blame all of our problems directly on people. We need to learn to cope.

We noted that some of the people issues are related to fear -- fear of failure when you do something different than before, fear of attempting to change and improve your processes and tools.

Communication is often seen as a source of complexity. One issue is that there is a lot of communication that is needed between project team members, but the well-known stereotype of most software developers is "people with no social skills".

Is this an area for improvement? Some would say that if you improved the communication skills of software developers, then productivity would decrease... more time chatting, more time in meetings, less time available for heads-down coding work.

Another related point about team diversity. In some workshop participants' experience, teams of mixed gender (often about 20-25% female) seem to be more "effective" in software development than all-male teams. This in anecdotal, but maybe there is a catalyst effect on communication, or just a self-selecting set of folks who are looking for a more diverse environment also spends more time thinking about design alternatives, quality issues, and other things that go beyond heads-down coding.

We do know that software professionals have differing levels of ability in dealing with abstraction, and that this might manifest itself as a communication issue. If a design model is written to contain 4 levels of abstraction, and the documentation requires working across the levels, there will be some developers who can't deal with "switching levels" in the same way as the developer -- a possible catastrophe.

Issue 4: List of Potential Silver Bullets

We ran a major brainstorming session -- the goal was to show some of the major Silver Bullet candidates of today -- just as Brooks gave a good list in 1987. The list also shows some of the reasons why the technologies and tools have failed to be a good Silver Bullet (or will fail in the future...). If we had to rewrite Brooks' paper today, we would probably select several of these technologies to highlight -- instead of AI, expert systems, graphical programming, and so on.

Here is the initial list of "potential silver bullets" that we took on during the workshop:

  1. High-level languages
  2. Grand unified distributed object infrastructure (CORBA)
  3. Model Driven Architecture (MDA)
  4. Tools and programming environments
  5. Objects
  6. XML
  7. Agile
  8. Aspects
  9. Open Source
  10. Globalization

1. High-level Langauges:

2. Grand unified distributed object infrastructure (CORBA)

3. Model Driven Architecture (MDA)

4. Tools / programming environments

Workshop participants discussed some of the examples of bad tools -- ClearCase is one tool that has caused negative reactions.

5a. Objects

5b. Frameworks 5c. Patterns

6. Markup languages and XML

7. Agile

8. Aspects

9. Open Source

10. Globalization

Issue 5: Essential versus Accidental Complexity

Most of us are not really sure if we understand the distinction between essential and accidental, so we invested some time in reading and thinking about how that term is used.

Most of the workshop participants were thinking that essential versus accidental is still a useful concept, but it has become a "fuzzy distinction" -- hard to judge when something is essential or accidental.

In fact, sometimes the fancier user interface feature is really "essential", but the developers still add some accidental complexity in the process of adding it.

Issue 6: Some neglected opportunities for significant improvements

In the search for "silver bullets" and "promising attacks on the essence", the workshop participants considered some areas outside of the traditional design and coding work:

Test automation is one set of technologies that are not used often enough in many software organizations. Some of this is due to inadequate tools and/or training, but a lot of it is just reluctance by managers and technical staff to change current practices.

Deployment is an important part of the software lifecycle which could be made faster and cheaper in many situations. In some organizations, deployment is the biggest bottleneck -- reducing development time may not always result in getting the solution out to the customers faster. This may be a good place to develop new tools and practices.

Requirements iteration is a big problem for many organizations -- when you are working in a domain where the requirements change faster than the developers can work. Good requirements iteration methods might not be a silver bullet, but because of the amplified impact of requirements errors on the downstream processes, this might have a great impact.

Tools that cross over between requirements and test can be most valuable, since good test development practices include linking tests to specific requirements items or use cases. Any improved communication between requirements writers and testers can be a good thing.

Iteration between requirements and architecture is often necessary as well. For example

So... requirements iteration occurs in many places in modern systems development.

Other questions to consider in the future

Due to time limitations, the workshop participants couldn't follow up on all of our thoughts. Here is a list of some of the questions and issues we might be interested in exploring later:

No Silver Bullet Panel

OOPSLA 2007 also had a No Silver Bullet panel session. Here is a link to some notes of the discussion in the panel: silver_panel.html.

Last modified: Oct. 24, 2007