There were six main issues discussed during the session:
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:
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.
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.
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.
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
6. Markup languages and XML
7. Agile
8. Aspects
9. Open Source
10. Globalization
Issue 3: Candidates for "what is the werewolf?"
Issue 4: List of Potential Silver Bullets
Here is the initial list of "potential silver bullets" that we took on
during the workshop:
5b. Frameworks
5c. Patterns
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.
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.
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:
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.