SEMAT was started November of 2009 with a manifesto, not unlike the Agile Manifesto:
Software engineering is gravely hampered today by immature practices. Specific problems include:
- The prevalence of fads more typical of fashion industry than of an engineering discipline.
- The lack of a sound, widely accepted theoretical basis.
- The huge number of methods and method variants, with differences little understood and artificially magnified.
- The lack of credible experimental evaluation and validation.
- The split between industry practice and academic research.
We support a process to refound software engineering based on a solid theory, proven principles and best practices that:
- Include a kernel of widely-agreed elements, extensible for specific uses
- Addresses both technology and people issues
- Are supported by industry, academia, researchers and users
- Support extension in the face of changing requirements and technology
The signatories include many wellknown names in the software and agile industries: Scott Ambler, Barry Boehm, Larry Constantine, Erich Gamma, Tom Gilb, Ellen Gottesdiener, Sam Guckenheimer, Watts Humphrey, Capers Jones, Ivar Jacobson, Philippe Kruchten, Robert Martin, Stephen Mellor, Bertrand Meyer, James Odell, Ken Schwaber, Edward Yourdon, …
SEMAT’s vision statement describes the kernel that the signatories have agreed to create: “The focus of the kernel effort is to identify and describe the elements that are essential to all software engineering efforts. Typical examples of the kernel’s coverage are teamwork, project management and process improvement. The kernel will also integrate concepts from other engineering disciplines. The kernel must accommodate change.”
Currently there are groups working on 5 tracks:
- Definitions – defining Software Engineering and related ideas
- Theory – identifying the supporting theories (preferably mathematical theories)
- Universals – finding the common a elements of software engineering to integrate into the kernel.
- Kernel Language – defining a language to express the other elements
- Assessment – ways to evaluate software engineering practices and theories
Ralph Johnson, co-author of the Design Patterns Book, worried that when academics say “theory” they mean math which is not what people in industry mean. He goes on to note that it's not even clear what software engineering is: “Do they mean all software development, or only software development practiced by people with software engineering degrees? Or with software engineering in their titles? What about the typical bank or insurance company, which has software development groups whose managers have little software development background, and where the average developer does not even have a CS degree, must less formal training in software engineering?” He goes on to point out that the real problem in the software industry is that most groups ignore things that have been known for 30 years.
Jorge Aranda agrees that the software industry has had its fads, but notes that many of these “fads”, Object Oriented development, Extreme Programming, etc. were once labeled as “fads” but are now an accepted part of the mainstream. By adopting such a conservative approach to software engineering he fears that future innovations will be stifled.
Only a year ago, Tom DeMarco argued Software Engineering was dead. DeMarco wondered if his early work on metrics was still relevant:
“Controlling Software Projects: Management, Measurement, and Estimation, played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.”
He goes on to say “Consistency and predictability are still desirable, but they haven’t ever been the most important things.”
Geert Bellekens supports SEMAT, saying:
I think its safe to say that we’ve all seen many different methodologies, but you can surely see that they all look pretty similar behind the surface.
If we put those different methodologies next to each other, and look at them from a distance I think we should be able to see the similarities and also clearly see in which way they differ from each other.
Now that is exactly what the SEMAT initiative is all about. Try to find the common elements in all the different methodologies, and rephrase them in a neutral, method agnostic way.
Scott Ambler has also come out in support of SEMAT saying that the industry needs something better than it has today; many of the right people are involved and he’s hopeful that something of value will be achieved.
What do you think of SEMAT? Will it crush future innovation? Will it create something of value? Or is the real problem teams that don’t even know that they’re missing software engineering practices?