More comments on SEMAT

I’d like to go back to the SEMAT discussion. As I mentioned in my previous post, I

I’d like to go back to the SEMAT discussion. 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 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 persons 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 construction companies 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 formulae. 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.

Share this articleShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone
Go Back