I’d like to go back to the SEMAT discussion. As I mentioned in my previous post, I
The SEMAT initiative looks to agree on the theories underlying software development, and wants to achieve its goals by building a “kernel” of widely agreed elements, extensible for specific uses.
I’d like to go back to the SEMAT discussion I initiated a couple days before. As I mentioned in my previous post, I believe that a widely accepted and sound theoretical basis is the key to moving from commercial practice to an engineering discipline.
SEMAT initiative looks to agree on the theories underlying software development, so in this sense it’s heading in the right direction. I also like that the list of signatories includes some of the key people in our discipline such as Barry Boehm, Victor Basili, Watts Humphrey, and David Harel.
SEMAT wants to achieve its goals by building a “kernel” of widely agreed elements, extensible for specific uses.
The elements of the kernel are called “universals”, and there will be a Kernel language for specifying them. The universals include things to do, such as specifying a system or concluding a project, things to work with, such as requirements and opportunities, competencies, such as analyst or developer, and patterns to apply. Different practices would then “slot” into the common kernel.
One idea that I like a lot about SEMAT is that they think that practices – and not methods – should be first class citizens. All previous efforts to define generic methods have failed for many reasons, one of them being that our field is too wide to define something that will be useful to everybody and at the same time have a level of detail that will make it significant. Therefore, concentrating on the different practices that one can apply without trying to predefine how they glue together in a process, is an interesting option.
But there’s one thing that worries me about SEMAT. Cockburn and Fowler have said that a better name would be meta-process-kernel. SEMAT seems to be concentrating on the theories underlying software methods, and not software engineering. And in the methods is where we have the least chances of being successful on the quest for theories.
Let me try to clarify this.
Suppose you have different contractors that build hospitals. One thing in which they will agree for sure is in how they do the calculations for the stability of the buildings. You can bet they will be using the same formula. They will also probably agree on some patterns for how the buildings are structured. And they will probably agree less on how they manage and organize a project, and maybe even less on how they manage the company as a whole.
In other words, although the search for theories in development methods might be fruitful, results there will be limited in value, because variation in methods is necessary and desirable up to a certain point. We may be more successful if we look for the “other” theories, the ones that refer to the more technical aspects of software engineering.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.