Welcome to my new blog! by Ivar Jacobson

For many years I have written postcards to those of you who have subscribed to them on our web sites.  I will discontinue writing the postcards, but instead talk about the many different aspects on software development on this blog.  And I am not the only one who will write for you.  I am so lucky because I am surrounded by world-class experts coming from around the world.  These people will publish notes here.  Thus, you will here from Kurt Bittner, Ian Spence, Svante Lidman, Pan Wei Ng and several other people.  I will introduce them as they come forward.We will use this blog to talk about our visions and our results.

I like to dream about the future, but I also would like to reach that future at some point in time.  I believe that when it comes to software, dreams only come true if the dreamer drives the realization of the dream.  Too many people have dreams.  Very few actually have the guts to make their dreams a reality.

In 1992 I wrote an editorial in IEEE Software that started like this:  “We all have dreams. Just a little over 25 years ago, I had a dream. I dreamed that the technology known today as "object- oriented" could be used to design telecommunications systems. I dreamed that this technology would be generalized and given a wealth of wholly different applications. I dreamed that the computer scientists who - in those days - ridiculed this technology and saw it as a dead-end street would one day accept it. I dreamed that this technology would in time become an indispensible element in the mainstream of computer science.”

In my summary I wrote: “Our long-term goal (which I hope we can achieve within another 25-year period) is to become as industrial in our handling of computer techniques as engineers are within their various disciplines. This requires, among other things, development of the architecture in large- scale object-oriented systems; it requires that the development process support project management as well as product management; and it requires that we find other, more sophisticated languages - specification languages as well as programming languages - compared with those we have today.”

Now 15 years after I wrote this article, it is interesting to see how far we have gotten.  We have got UML which is a standard modeling language for software development.  Before UML we had lots of different notations with almost no semantics.  UML basically took all of these notations out of the picture and replaced them with one single notation with reasonable well-defined semantics.  It is not perfect but it is practical.  It is being applied around the world for all kinds of software and for all kinds of models including business, requirements, architecture, analysis and design. 

When it comes to process and methodology, we have also made substantial progress.  When I wrote the IEEE article there were more than 26 published methods identified by the OMG (Object Management Group).  The most successful one of these methods (and tragically basically the only one that really survived) was Objectory which became the Unified Process. 

In parallel with the success of the Unified Process, new kinds of methods have come into play.  The most successful of these other methods are labeled agile.  However, the meaning of agile has been confused by its proponents.  What really is unique about agile is that it cares about people.  Thus it is about social engineering.  No process has ever developed software.  Only people develop software.  They may get help by tools.  They may get advices from process or methodology, but eventually we must make our people motivated and competent.  Nothing is as effective in getting software quickly and at low cost as having motivated and competent people.

Given that no methodology has everything you need, and even if it has most of what you need, it won’t be the methodology you want to use in ten years time.  New ideas and new technologies will come into play.  These will come from individuals and companies throughout the world.  If you try to extend your methodology with these ideas, it will grow until it collapses under its own weight. Instead of publishing branded complete processes or methodologies we should focus our skills on single practices.  Usually a methodologist is good on one or a few practices, but not on all practices that a team needs when developing software. 

Now it is time to formulate one of my new dreams.  My dream is that great people around the world will contribute their best practices to the world maybe in the form of a community.  These practices can be of different kinds.  They can be technical such as those from the Unified Process camp, or they can be social engineering practices from the Agile camp.  A team can then select from these practices and compose the selected practices into a way of working that helps the team develop good software, quickly and at low cost.  This is my dream.  Now, we are not just dreaming.  We have come a long way in realizing this dream.  We have developed a practice platform EssWork where you can find a whole set of practices, you can author your own practices and you can select the practices you like and compose them.  There is still a lot to be done before we are finished, but with your help the dream will come true.



TechED by Ivar Jacobson

Barcelona is my last stop on an around the world trip that started Oct 17 from Stockholm. That morning I gave a talk to key developers at a key Swedish company developing key telecom products :). After my talk I rushed to the airport and flew to Tokyo to meet some key people from large software companies. After Tokyo I went to Taipei, followed by San Francisco and now Barcelona. This is my 6th around the world trip this year with one more to go before the end of year – three less than last year. As you can see I am slowing down.

Barcelona hosted one of the largest software conferences this year, the Microsoft Tech•Ed – Developer conference and yesterday I gave, together with my colleague Pan-Wei Ng, a talk on Next Generation Process (NGP). Here is the core idea of the talk:

The world of software development is constantly changing and evolving. New ideas arise all the time and existing ideas go in and out of fashion. Software development processes find it very hard to keep up with this rapid rate of change, especially as they find themselves quickly going out of fashion or becoming bloated as they bolt on more and more information. Teams find themselves struggling as they try to mix-and-match practices from various sources into a coherent way-of-working.

A new approach to capturing and sharing experience is required. In my company, Ivar Jacobson International, we have developed a fundamentally new way of managing software development that downplays the importance of process – in particular big process. Instead practices become important. A practice is a way of working with a clear beginning and a clear end. Following a practice should give a clear result of value. Instead of trying to give an academic definition, let me give some examples: Iterative development is a practice that you can imagine to use separately to how you specify requirement or define your architecture.

  1. Practices are First Class Citizens
  2. Practices can be made smart to truly help the developers in their work, this is achieved with WayPointer
  3. Practices can be used individually or in a multitude of combinations
  4. Process is just a composition of Practices, and
  5. Teams compose the process they need by selecting just the practices that they want to use

As you can see this is a paradigm shift. We move away from working with a big monolithic process (like RUP) to working with practices. Process is downplayed to just become a composition of practices.

To enable this, a number of innovations are required: innovations related to the way that practices are collected, presented and applied. We have developed two components to realize these innovations:

EssWork is a new set of tools for deploying practices in an organization. These tools allow you to author practices separately and to compose them to a process. They allow you to use a completely new way of learning, adopting, scaling up, and changing your selected practices. You use cards to describe your practices, to plan your project and to guide you in developing software. Cards are good because they force us to be very brief in describing process elements. You focus on the essentials, which makes practices very lightweight.

EssWork is available on top of several platforms: Eclipse, EPF, VSTS so you can have the same process independently from which vendor tools you use. On top of EssWork we have built a first set of eight practices called EssUP (Essential Unified Process).

EssUP is just a subset of all the practices we eventually will see on EssWork. Five of these practices are traditional Unified Process practices: use cases, architecture, iterations, components and products. Moreover, there is one practice which supports social engineering practices unique for agile methods, and one practice for process improvement derived from the process improvement camp such as CMMI.

However, we are not dogmatic about which practices you should use. You can replace any practice that we offer with a competing practice from your favourite methodology. You can also add practices that you have discovered yourself. Mix and match is our recipe.

Best of all: EssWork and EssUP are going to be Open Source! I can’t give a date, but it will happen as soon as possible.

The presentation was completely full (around 500 people) which was a fantastic result – there were people standing in the auditorium and watching on the remote screen outside So there is much to do going forward.

Various Podcasts were arranged. This is one: