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

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

The software development community has been talking about practices in an informal way for a very long time - more than 50 years. In the way the community talks, a “practice” is just something that people do, a habit they have that may be good, or perhaps not good. Talking about practices in this way makes for good conversation, but it is hard to figure out how to combine good practices into something meaningful.

I like to talk about practices in a more precise way, so I will refer to these as Practices (with a capital ‘P’). With a more precise definition we can do some interesting things: we can combine them (or compose them) in interesting ways, and we can separate them to allow us to replace a practice with a better one. Read More

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

More than twelve years have passed since UML, the Unified Modeling Language, became a standard. During these years the perception of UML has ranged from the heights of the heavens to the depths of the earth.

At the beginning of the 1990s there were 26 published methods on object-orientation, most methods with its own notation. It was to address at least the notation problem that UML was conceived. As most of you probably know, Grady Booch, Jim Rumbaugh and I initiated the design of what became UML, but very quickly many other great people joined the effort and OMG undertook to launch the result. UML quickly made most other notations superfluous. Along with the notations many methods also fell by the wayside, leaving the Unified Process, which had embraced UML, as a de-facto standard along with UML. UML’s adoption spread like wildfire. Read More

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

Traditionally many large software organizations have one group to write requirements, other groups design and code, and still others to test, etc. Thus, every group has some form of specialist competency.  This is a kind of “siloed” organization. Project work is moved from group to group, with hand-offs between groups that result in  delay and inefficiency due to loss of time and important information at each hand-off.   This is not agile. Read More

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

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