BT

SEMAT - Software Engineering Method and Theory

by Mark Levison on Apr 14, 2010 |

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:

  1. Definitions – defining Software Engineering and related ideas
  2. Theory – identifying the supporting theories (preferably mathematical theories)
  3. Universals – finding the common a elements of software engineering to integrate into the kernel.
  4. Kernel Language – defining a language to express the other elements
  5. 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?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

OO is the problem by Jean-Jacques Dubray

"Software engineering is gravely hampered today by immature practices...little understood and artificially magnified"

I have no idea of what SEMAT is talking about.

I am a bit disappointed though that SEMAT does not make explicit the overweight representation of "Object Orientation" in our industry, which frankly is at the core of the problem. This is because OO does not let you "code" your solution with semantics aligned with the class of solution you are building (information systems, embedded/RT systems,...). This is why there are so many "recipes" and placebos floating in our industry.

If "code" semantics were specified for a given class of solutions in a technology and architecture independent way, we would not need any of that.

On a positive note, I am glad SEMAT is focusing on: "Support extension in the face of changing requirements and technology", again, this is something that OO missed altogether and "cool" approaches like REST continue to oversee altogether.

Fashion Victims by Paul Korney

"The prevalence of fads more typical of fashion industry than of an engineering discipline."

I just love that statement!

I don't see this as stifling the use of new tech at all. On the contrary, encouraging a practice that determines whether a technology is applicable to the problem at hand, and thereby averting the disasters that typically get associated with the new tech, can actually speed the technology's adoption.

IT shops gratuitously using the 'most cool' techniques and technologies without really vetting or understanding if and how they benefit the customers/stakeholders is, for me, still the biggest problem we have. I'm happy to see this being explicitly recognized as a serious management and people problem within the IT industry community.

I plan to look into how I can help; I hope other IT people (and customers!) living in the trenches can contribute also so that this isn't just an academic effort.

Diversity and Patience by Mark Kennaley

Perhaps the movement can be viewed as a group of folks who have experienced the same things occuring in our industry (or perhaps only certain aspects within the CFA), and want to do something about it. And they have basically exercised their right to assembly. With the diversity present in the group, or the amount of experience present in the effort, obviously it will take time. Arriving at consensus with such diversity (as opposed to homogeneity of thought) is no easy feat; but arguably such an assembly is worthy of at least respect. I like to think of it as the formation of the United Nations for Software Development - not that this is perfect in any sense. Hopefully the diversity will grow at a sustainable pace, something I believe should be a goal but will require patience. And sure, right out of the gate the NATO 1968 conference and the term "Software Engineering" causes controversy. This needs to be resolved, albeit 42 years later. See www.fourth-medium.com/wordpress/?p=150 as an attempt to put this term in context. To ignore that the term is somehow not relevant is, well, ignorant. The issue is how does it play within the field of Software Development. This turns out to be laced with sociological complexity - which makes sense, as software is so pervasive in society. And after all, software development is all about people.

On the issue of somehow implying "big math" and "grand theories", this too seems to be more ideological reaction - kinda like the Positivism vs Meta-physical schools of thought when dealing with Sociology. I believe, as I have recently written in detail about, that system's thinking is not a bad thing, science is not a bad thing, studying the world around us is not a bad thing. So I guess I am a Positivist - but hey, so is Steven Hawkins so that isn't so bad I guess :o)

I am participating (you can see my work on the SEMAT site) because I believe the world of software development methodology has become a cottage industry which creates a HUGE amount of us-vs-them waste; or as Scott Ambler calls it, "versusitis". I believe that all this waste and noise can be reduced by de-mystifying branded methods leveraging System's Thinking, which is backed by some pretty intense math and science if we go beyond just name dropping.


Mark Kennaley
President & Principal Consultant
Fourth Medium Consulting Inc.
Author of SDLC 3.0: Beyond a Tacit Understanding of Agile
Blog: www.fourth-medium.com/wordpress
Twitter: www.twitter.com/sdlc3

Duplicating effort made elsewhere by Jean-Simon LaRochelle

I think this is going to duplicate some of the efforts made on the SWEBOK (software body of knowledge) project.
I hope those guys take a look at the SWEBOK. Those interested can have a look at: SWEBOK site

Re: Duplicating effort made elsewhere by Roger Itai

I think the same. I hope those people can help to improve SWEBOK 2010 version.

Re: OO is the problem by Mark Levison

Jean-Jacques - I wondering if the underlying problem is that teams don't understand how to apply OO and other development approaches. I'm probably pretty closely aligned with Ralph Johnson when he says that he thinks 50% of teams don't get anything from the past 30yrs of software development history.

My personal bug bear is that teams that don't learn and improve.

Cheers
Mark Levison
Agile Pain Relief Consulting

Re: Fashion Victims by Mark Levison

IT shops gratuitously using the 'most cool' techniques and technologies without really vetting or understanding if and how they benefit the customers/stakeholders is, for me, still the biggest problem we have. I'm happy to see this being explicitly recognized as a serious management and people problem within the IT industry community.


Paul - this an interesting statement but I'm wondering if you can give us an example of what you mean here?

Cheers
Mark Levison
Agile Pain Relief Consulting

Re: Duplicating effort made elsewhere by Mark Levison

Jean and Roger this is quite interesting until your comments (and a twitter comment), I'd never heard of SWEBOK. Can you give us some more idea what it is? I've asked Ivar Jacobsen for a comment - we will see if he has time to respond.

Cheers
Mark Levison
Agile Pain Relief Consulting

Re: OO is the problem by Jean-Jacques Dubray

Mark:

it is of course impossible to rule that out, but in general what I have experienced a general mismatch between OO semantics and semantics that are common to a solution domain. Examples include:
- process
- entity-relationship
- entity / resource lifecycle
- concurrency
- service
...

The boundary of "not understanding how to apply" vs "not being appropriate/optimal to build a solution" is of course hard to define. However, the level of effort of applying OO (with patterns, recipes...) vs the level of leveraging solution oriented semantics (BPM, ...)

IMHO, the problem is that whatever semantics is identified in the industry, the vendors always reify them into OO runtimes. Again, IMHO, there lies the problem and hence the solution.

OO was invented well before modern architectures emerged and since then it has been a struggle to use an OO programming model in these architectures. IMHO, this cannot be resolved by more training, smarter people, ...

I don't mind keeping the OO runtimes, but IMHO, we should focus on solution oriented semantics which are then compiled or transfored in a particular architecture / programming environment.

Re: Duplicating effort made elsewhere by jean-simon Larochelle

Mark,

Here is a link to the IEEE site that seems to be hosting the project. I won't try to give a description of the project because you will find a better description (as well as other information) on the IEEE site.
I've been using the main document of the project for a few years (the draft version) and find it quite useful.

Re: Diversity and Patience by Mark Levison

Mark - I've been giving this alot of thought and am struck as I read through the SEMAT material how abstract it all was. Alot of material was devoted to the kernel and what it might entail. I can't see what value the world will get from this. I see teams struggling every day, struggling trying to do waterfall, RUP and even Agile. A common language wouldn't help - they wouldn't know it. They wouldn't even have heard of it. If the SEMAT spent more time focused on concrete vs. abstract things then it might get more attention from me.

I also noticed something about Best Practices, I'm allergic to these see: There are no Best Practices

Cheers
Mark Levison
Agile Pain Relief Consulting

Re: Diversity and Patience by Mark Kennaley

Mark - Yes "Best" in front of practices was a little unfortunate. But if you look at some of the contributions thus far (like either my or Scott Ambler's), the issue of "context, context, context" is front and center. In my case, I call for the elimination of branding of "whole methods" that is so rampant in our industry; when you look at the history of how we arrived at this point, it actually looks alot like a branching anti-pattern. A continual cascade of re-invention vs integration, isolation vs true collaboration. But easy to understand - there is money to be made by jumping on the latest named fad.

My work is focused on creating a single "Complex Adaptive System of Patterns" - leveraging the experience from Lean + Agile + UP lineages; I leverage Control Systems Engineering (PID Control, Stochastic Control, Adaptive Control) as the yet-untapped body of knowledge to make the case for how to do this. This idea provides a very sound basis for understanding why Agile works the way it does, why "Accidental Waterfall" doesn't, beyond a tacit or folklore level.

Only time will tell if my ideas catch on with the SEMAT group, but these extremely concrete contributions are at least visible and being discussed.

Cheers,

Mark Kennaley
President & Principal Consultant
Fourth Medium Consulting Inc.
Author of SDLC 3.0: Beyond a Tacit Understanding of Agile
Blog: www.fourth-medium.com/wordpress
Twitter: www.twitter.com/sdlc3

Re: Fashion Victims by Paul Korney

Sorry for the length of this, but here are a couple of examples:

Party Line: RUP and/or 'Agile' -
The last 5 client IT shops I've worked at (2 F500 financial, 1 F500 supply chain, 1 government, 1 non-profit) all claim to use both RUP and 'Agile' (sometimes both on the same project??!!). The reality is that there is no sign of either process actually taking place; for example, no active customer involvement at the project or program level. These claims are typically driven by mandates from middle/upper IT management to use something other than an ad hoc process without any of the necessary support (training, coaching, etc.) for transforming the existing processes and organization. Due to the C&C top-down cultures, these claims become nothing more than the party line.

One Size Fits All: REST -
Use of REST as an unqualified replacement for existing infrastructures like SQL, LDAP, JNDI, MQI/JMS and other such plumbing in a J2EE shop. The original (good) idea was to better support systems integration by providing modern technology 'wrappers' around some ancient pre-existing production systems. Somehow, this is turned into an ‘architectural’ mandate requiring all systems and services to expose RESTful HTTP interfaces even where the J2EE architecture already was providing a solution.

Tail Wagging the Dog: Supplier Driven Change -
Use of a new management/vendor relationship to drive unqualified technology 'upgrades' of working production systems. In all cases, the efforts include several multi-year projects to rewrite existing production systems to accommodate whatever was sold. A variation on this is when a detrimental technology *must* continue to be used because some middle/upper IT management person once spent a lot of money on it and is now married to the decision.

My point is that none of this has anything to do with delivering value to the customer ultimately paying for this. In fact, and again across all my examples, the IT shop is openly hated and cursed by their LOB customers. This is an old story, but I believe we can do better by making SD a true business and engineering discipline. I believe that SD should be a distinct and strategic discipline within an organization and/or LOB, separated from the IT division whose concerns are mostly with non-strategic and commodity assets. I see the SEMAT effort as helping to define SD as such a distinct customer oriented discipline whose value can be measured by its customers.

Re: Fashion Victims by Chris Webster

Paul K. makes some excellent points. The perils of "one size fits all" are definitely part of the problem here, whether the "one size" is REST, OO, SCRUM, RUP etc or whatever.

I think this is also related to the old "computer science" versus "software engineering" debate e.g. see Steve McConnell on Software Engineering, not Computer Science.

My own experience, as a plain old database developer in commercial and public sector IT, is that we suffer disproportionately in this industry from technical fads and fashions, and in the last 10 years I have seen a significant shift away from the concept of software development as engineering towards the increasing influence of the computer scientists on mainstream commercial IT.

Of course, there are good reasons to accept the significant differences between software and hardware in engineering terms, and to recognise the limitations of some previously conventional approaches to software development, which is one of the reasons for the rise of agile methods.

But I think these changes have also had a negative impact in terms of shifting the focus from thinking about how to deliver robust and maintainable systems which meet the client's needs, towards a seemingly endless cycle of experimentation at the client's expense.

In the worst cases, I have seen entire projects subverted by wannabe computer scientists experimenting with the latest cool technologies and agile variants, while the client watches their project budget disappearing into the sand without ever seeing a single working piece of software. This seems to be a particular problem in the public sector, where clients are often dazzled by hight-tech BS from vendors, and where there is usually less focus on cost-effectiveness.

If you're a software house developing new technologies, then of course you need good computer scientists. But if you're an IT department for a large commercial company whose business is not software, then you need to focus on the needs of the business, not the latest trends in computer science. Let somebody else take the pain of using bleeding edge technology, then learn from their mistakes.

So any new forum that might help to introduce some much-needed discipline, rigour and realism into the practice of software development in the real world can only be welcomed.

Follow Up by Paul Korney

I would like to follow up this article with references to some of the criticisms from, for example, Martin Fowler martinfowler.com/bliki/Semat.html and Alistair Cockburn alistair.cockburn.us/A+Detailed+Critique+of+the.... It is hard to get a handle on exactly why there is a problem, but it appears to revolve around the age-old conflict between art and science in engineering. Specifically, the use of math based formal methods (science) vs. the use of human centered 'methodologies' (art). At least, that is my read...

Could this conflict be better addressed by working, first, on building a consensus about if/why software development is different from any other product engineering, where the question is not whether these kinds of techniques are generally useful, but rather on how best to combine them to be effective for the needs of developing a specific product.

Re: Follow Up by Jean-Jacques Dubray

Paul:

a couple of remarks. EE went to a phase of ultra componentization that transformed the work of "designing" into an "assembly" of components. Later, though, components and assemblied proved inflexible and hardware engineers became software engineers, writing some code to specialize the components to a particular application.

The software industry never succeeded in achieving the delivery of software components that could easily be assembled. Spring, SCA and OSGi are definitely successful examples of "components + assembly" but they remain relatively marginal (or not enough wide spread, .Net does not have such a mechanism for instance).

So before even starting to investigate the methodology, people would be greatly inspired to revisit "modern" programming models and offer better standards or general approaches, on which methodologies can be built.

In the end, it doesn't make much sense to develop a methodology without the foundation of a target programming model (SOA/SCA, WOA, MVC,...).

Re: Follow Up by Mark Levison

Thanks for the links, Paul. I'd been hoping to get Alistair to publish here :-)

Having witnessed attempts to describing programs with formal specifications (Parnas) in the 80's, I'm not convinced that you describe anything useful on a human/product scale with mathematical rigour. I think that may produce something interesting but I'm struggling to see where it will be applicable.

Personally I'm focused on humans, who're not plug and play, who can't be described with a symbol. My interest is in helping clients deliver value.

Cheers
Mark Levison
Agile Pain Relief Consulting

Re: Follow Up by Mark Levison


In the end, it doesn't make much sense to develop a methodology without the foundation of a target programming model (SOA/SCA, WOA, MVC,...).

Jean-Jacques - that's an interesting statement. I've seen Scrum/Agile even RUP work on a variety of projects from Rich Clients, Web Apps to Servers. I've even seen Agile/Kanban applied to non-work family life, churches (see Jeff Sutherland's writing on this). So what makes you say that methodologies should be tied to programming models?

Cheers
Mark Levison
Agile Pain Relief Consulting

Re: Diversity and Patience by Mark Levison

Having read Alistair's notes on the subject - I will say only that the exercise resembles much of what Parnas tried to do in the '80s. I will focus on helping humans and not the math.

Cheers
Mark Levison
Agile Pain Relief Consulting

Re: Fashion Victims by Mark Levison

Paul in 5 yrs time you will be able to add top down implementation of SEMAT to your list your first list of failures. Top down implementations of any change that don't recognize the time and effort involved in transforming the culture will fail. Doesn't matter if its Agile/RUP/Waterfall - most people don't want to change and will resist it. To succeed you have to think about involving them. How one does this is far beyond the scope the comments here.

Cheers
Mark Levison
Agile Pain Relief Consulting

Re: Follow Up by Paul Korney


Personally I'm focused on humans, who're not plug and play, who can't be described with a symbol. My interest is in helping clients deliver value.


Mark,
I agree wholeheartedly with this sentiment! I guess my issue is really that 'software engineering' (if there is such a thing) should not be so dissimilar from other engineering practices. To a large extent what I mean by this is that software should be put in a proper contextual perspective. For example, when I am charged with building a web site, I am 'engineering' a web site product, not a software product. I build or buy software for this web site in the same way I build or buy windows and bricks for my house. Certainly, whatever I choose will need to be engineered too, but this is relevant only in context of the end product.
Too often, discussions about building software confuse the software with the processes and products the software is being built for. It is this confusion that I believe causes so many problems for software intensive projects.

Re: Follow Up by Mark Levison

Paul - I'm in agreement with Tom DeMarco - I don't think there is a software engineering - a discipline with rules of thumb, or calculations that you can make about load, stress etc. I'm not sure there ever will be. But if this does happen we need decades more experience.

Cheers
Mark Levison
Agile Pain Relief Consulting

Re: Follow Up by Paul Korney

Probably true in the sense that the article uses the term. More important though is this statement which says well what I'm trying to get at:


The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.

Link to article:
www2.computer.org/cms/Computer.org/ComputingNow...

Re: Follow Up by Mark Levison

Agreed and I think the mathematics and rigour of SEMAT approach will not help in the long run.

Cheers
Mark Levison

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

24 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT