Skip to Content

In my Blog earlier this year about A Timeless Software Problem, I gave some facts which support that software engineering must be seen as a pretty immature discipline and that the consequences of this immaturity translates into astonishing costs – or better – an astonishing waste of resources in the hundreds of billions of dollars per year.

When laying a hand on code myself, I often have the feeling that after decades of history of this engineering discipline, many things somehow should be possible much easier, faster and more reliably than they currently actually are. I don’t think my impatience is the only reason for this feeling. Instead, I think that despite of all the so called breakthrough technologies, there has been very little real breakthrough. Likewise, the jungle of development methodologies seem to me more determined by assumtions and fashions than facts. Or to cite SEMAT: “the way most of us develop software is immature and in need of being revolutionized. Yes, these are strong words, but the initiative SEMAT is supported by more than 30 renowned scientists, scholars and practitioners in the software engineering field, including leaders from major industrial corporations (e.g., ABB, Ericsson, Fujitsu, IBM, Samsung, Microsoft, etc), academia (researchers, professors, institutional managers), and thousands of practitioners around the world.”

SEMAT (short simply for “Software Engineering Method And Theory”) is a relatively new initiative. It is a initiative of people that believe that there is something very fundamental missing in the discipline: a solid theoretical basis, a philosophy of the discipline. Like for early sciences, software engineering is missing a theoretical underpinning for it’s approaches, practices and technologies. Here are the main points of SEMAT’s motivational statement:

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.

SEMAT makes the distinction of two main domains that need to be targeted: “Methods & Tools” and “Professionalism & Craftsmanship”.

On the “Method &Tools” side, the problem according to SEMAT is, that there is a myriad of technologies and methods out there, but a lack of means to assess and compare them, and as a consequence, there is no solid foundation for improvements (see also my last A Timeless Software Problem on this theme). The way forward they propose is to identify “universals” that make up the essence of a specific method. The goal is to define a “small kernel language” that would enable to discuss methods in a unified and normalized way, making it possible to assess and compare them. Quoting again:

The way forward is based on the observation and understanding that:

  1. Every method is just a composition of practices, either human- or technology-related.
  2. Practices are reusable over many application areas and technologies.
  3. Underneath all practices is a small kernel of universals described and composed by a small kernel language.
  4. Universals are things that we always have, do or produce when building software.
  5. Practices and universals are described by a small Process Kernel Language.

On the “Professionalism & Craftsmanship” domain, SEMAT takes a human centric perspective and goes in my opinion in direction of the agile manifesto. It suggests a codex of professionalism. No client of a civil engineer would try to get a building or bridge build despite of the professional warning that it won’t stand. A similar attitude is demanded for the trade of software engineers, where there are plenty of examples of projects, where failure could have been seen erlier.

On top of that, and probably as a result of a barrier between academic research and industrial practices (a nice reference on this subject: “Things They Would Not Teach Me of in College: What Microsoft Developers Learn Later“, Eric Brechner), education is an important part to be adressed on this track:

Code can be written by anyone at any time, but what makes us professionals?

  1. We must be proud of what we do. We must be able to say “no” to either the boss or the customer, if necessary. We have our professional practices and these cannot be compromised.
  2. The boss and the client must accept the fact that our work is technical in nature; so let them think we are geeks, but we have ethics and process.
  3. Anything that is worth doing should be done well and with quality. When we ship code, we must know that it works. Acceptance testers should not find any errors.
  4. Become competent through an apprenticeship program. Choose a master and learn from him or her.  After some years you may select a new master and also learn from him or her.

I became aware of the initiative earlier this year. It is gaining a lot of momentum and has a very impressive list of supporters and sponsors now. You’ll hear from me in future blogs if I come across remarkable outcomes, so stay tuned.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Otto Gold
    Hello,
    I would like to thank you for the text. Even if this is a long way to go, we must start somewhere and sometimes. We can start from here. Something like “the future starts today”:))
    I wonder if you´re going to elaborate on the topic in the future blogs? I would like to read it. I feel the same about the waste, about the problems and like the harmony and the message of your text very much. You could be a man, who will contribute to the Change.
    That would be very nice!
    Best regards, Otto
    (0) 
  2. Joern FRANKE
    Nice article. I think there is a need for a change in the research community and you are right: We are creating a lot of artifacts, but we do not care if they work in a human-computer-system context. This is a fundamental problem in computer science: Strange use cases are developed (I wonder if the travel agencies know how well the travel-booking process for hotel, a flight and sometimes a rental car is supported by technology?!) and researchers try to avoid facing their artifacts with reality. I think even little experiments with users and systems can be very helpful with this respect. On the other hand it is very difficult to do empirical research with software or develoment processes, because you can base them only on case studies to get insights. This so-called quality research still needs time to get accepted in the research community.
    (0) 

Leave a Reply