SEMAT (Software Engineering Method and Theory): A Call for Action by Ivar Jacobson

We are some people who have observed software engineering theory and practice of the past decades and have realized that it is now time to revitalize this discipline. We have been quietly planning a “revolution”.

For those who have been following my columns may know that, for a very long time, I have been talking about that we need a theory of software engineering. See my two blog entries, “A problem to fix: We don’t understand the nature of software engineering” February 2009, and “Someday we must become professionals!” March 2009, which describe my thoughts on this issue when it all started over a year ago. Read More

Closing the Gap between Business and IT by Ivar Jacobson

From almost the dawn of the age of software more than 50 years ago, there has been a communication gap between business and IT. For almost as long we have sought solutions, but they always seem to elude us.  Meanwhile, the gap has grown into a chasm that now needs a fairly substantial bridge.

From the business you may hear that ”we have no confidence in IT’s ability to deliver useful solutions”, or “we have limited visibility of progress, risks and problems”, and “we don’t know how we should measure the value of our investments in IT.” Read More

A Day of Honor by Ivar Jacobson

Lima, Perú, October 21, 2009

This time I have something to tell you about my visit to Peru. I had been nominated to receive an honorary Doctorate degree from the University of San Martin de Porres (USMP) in Lima Perú. USMP is one of the most prestigious universities in South America. Thus, when I got the offer from USMP and saw people who previously had been awarded honorary degrees, I felt I was in great company. James Martin (the father of case tools and much more) and Nick Negroponte (the founder of MIT’s Media Lab and the “One Laptop per Child” Initiative) received the honorary degrees in 1997 and 2007 respectively. Read More

In need of a theory for software engineering by Ivar Jacobson

To an external observer it would appear that the consensus about the way software should be developed changes dramatically every second or third year, more frequently than the whims of fashion. Trends seem to come and go with no rhyme or reason, and it seems that the label you adopt is more important than the results that you get or the things that you actually do.

Are we working in engineering or in a fashion industry?

Have you ever taken the time to investigate a new method or practice only to find that it is just the re-branding and re-gurgitation of ideas that you have seen many times before? Read More

Taking the Temp on Agile by Ivar Jacobson

A couple of weeks ago Kent Beck delivered the keynote at a conference in Gothenburg, Sweden.  He began by saying that, in the US, agile already starts to get old.  Programmers are tired of all these daily meetings where they have to be social.  They want to code – they don’t want to talk. This being said by the father of XP and the individual who is probably most associated with triggering the whole agile movement – a fantastic accomplishment that has my greatest respect.

We also have had many indications that, at least in the US, people are getting tired of talking about agile.  A CIO of a large company with whom we work won’t use the term “agile”.  A CTO from another very large company with thousands of developers where we have been rolling out practices, says he doesn’t care about approaches – agile, RUP or whatever - only the result count.  He has distanced himself off from agile since it creates religious zealots in his organization and this zealotry only gets in the way of achieving results. Read More

Someday we must become professionals! by Ivar Jacobson

We software people run after the latest fashion.  Five years ago we ran after RUP, now we run after Scrum, and in five years we will run after something else.  At each transition we start over, failing to learn anything; we fail to keep what is working and improve what is not.   In my two latest blogs I have talked about how we can diminish the tiresome element of religion and fashion when it comes to methods and processes.  This is a precondition if we are to ever become software professionals.

The solution looks somewhat like this:  all methods have quite a lot in common.  After all, they are all used to develop software, and there are certain things that always need to be done when you develop software.  Let’s call this the “kernel”, a kind of elementary process which is the mother of all methods.  With this kernel as a base all methods can be described in a uniform way, as extensions to this base. Read More

Let’s fix the problem: Understanding the nature of software engineering by Ivar Jacobson

In my last blog I described our immaturity when it comes to software development. Companies follow the latest fashion and jump from method to method without standing on what they already have adopted and that is working.  This is expensive and it results in bad software.  When I am upset I say that it is stupid and ridiculous.  How do we change this?

We need a basic theory describing what software development actually is. In my opinion, this theory is right in front of us - we just need to grab it. We can start with all these methods, processes, and practices and find the "truth" of software development. We have already done this in my company and the result has been used by hundreds of companies around the world. Read More

Giving requirements a bad name by Ivar Jacobson

A while back I was giving a presentation on requirements errors and someone made the observation that they thought the term "requirement" was, in itself, misleading. The  gist of his argument is that the very term implies something that is "required", that it has to be done.  In reality, most "requirements", at least as initially stated, are somewhat vague statements of things that could be done, but they often need quite a bit of work to determine what is really needed.  It would be better to call them, at least initially, "wishes".


Unfortunately we are probably stuck with the term "requirement", but it can help to realize that as initially identified "requirements" tend to be vague, filled with incorrect assumptions about what the real problems and solutions look like.  Some organizations call these sort of things "stakeholder requests", which gives them a way to capture them without anyone inadvertently assuming that these are the actual requirements.  They then go through an investigation and refinement process before discovering the actual "requirements".  Along the way, various other kinds of things may be discovered: needs, goals or objectives, desired outcomes, as well as terms (such as would be found in a glossary), among other things.


The important thing is not how you categorize (this can get out of hand as well), but that you recognize that even when someone tells you something is a requirement you should not just accept their statement at face value - you need to make sure you understand the real need, and especially what they need to achieve. Only by doing so will you know whether the thing they are asking for is really "required".