What Drives Me by Ivar Jacobson

What Drives Me

“The best way to predict the future is to invent it!“ (Alan Kay)

A few days ago, a very simple but thought provoking question was raised to me: “what it is that drives me?” The simple truth is that I do not know. But I do know what it is that does not drive me. It is not about money. Actually, never has it been about money. Neither is it about power. I am happy to step aside and I am happy to delegate both up and down. It is not about popularity – but I do like to be appreciated for what I do.

No, it has to do with helping others improve themselves over and over again. I get a kick out of seeing others become successful because I helped them. It was like that in the late 1960s and the ‘70s when the Ericsson AXE system beat all competition and won every contract thanks to being component-based. Similarly, when Rational was successful because of UML and Objectory. And Telelogic because of SDL. I am happy when people are successful thanks to use cases.

To constantly improve, I have to come up with new ideas. But I can’t stop at just creating new ideas; I have to get these new ideas widely accepted, usually in the form of standards. The latter I will talk about in another column.

Then, how do I get new ideas? Do they come like flashes of genius? Unfortunately they do not.  Almost always, they come after a long period of painful, deep and heavy thinking.  Basically, I say to myself “now you have to think about this issue, and this issue is just vaguely known or just a symptom of a problem”.  Thus I have no clear problem definition, so first, I focus on identifying the core problem and once I have found it the solution lies close at hand. Or more simply put: find the problem and more than half the job is done. Since, the problem is new, there are usually no solutions already out there; which means I can work to find a solution in an open space. This is the trick.

Unfortunately many people do not worry about finding the problem; they feel they should only worry about the solution. I have heard many academics say that the industry does not know what problems they have, so how can they expect their problems to be solved? Even when an industry representative really tries to describe a problem, but doesn’t use the terminology of the science in question, his or her words sound like noise and he or she is not taken seriously. Academics should instead listen carefully and actually make every effort to seek to find the problem underlying what they are trying to say.

There are exceptions.  When ITU (International Telecommunication Union) worked on the standard programming language CHILL back in 1978, I presented to the workgroup (about 20 members from the industry, all language experts) a new communication mechanism called ‘signal’.  It was a message with ‘send no-wait’ semantics instead of the more traditional message types based on ‘send wait’ semantics.  The whole group was against my proposal.  And, when a group of 20 people downplay a proposal it can be quite ugly.  However, there was one man who stood up for my proposal – professor Dines Bjorner from Denmark.  He said he would study my proposal and compare it to recent work by Tony Hoare on communicating sequential processes.  After a couple of weeks of work, Dines Bjorner had formally defined signals.  He presented the new idea to the group saying that this is what the world has been waiting for the last ten years; and that it is time to retire the old ideas.  Two years later all of the major telecom vendors had turned to signals.  The language designers hadn’t seen the new idea, but their developers had been waiting for this change for a long time.  The moral of this story is that academics should go out in the field and learn.  The field is vast and there are lots of important problems waiting to be discovered.  You just need to listen respectfully and you will harvest the most beautiful ideas.

My ideas always come in pairs – a problem with a solution.

First I find a problem and then I find a solution to that problem. It is not the reverse, first finding a solution and then looking for a problem to that solution.

It starts with some known negative symptoms that I suspect are hidden in a deeper problem. I look for the core of the problem. When and if I find a problem that is not identified by the outside world; the solution is usually close at hand.  And my melancholy transforms into great relief.

In this way, a number of ideas have come to me over the years. In 1967, when I saw Ericsson wrestling with the problem that a computerized telephone exchange consisted of two giant systems (a program system and a database system) with an intense very low-level communication protocol (basically read and write only), the solution was to build systems with components. Sequence diagrams were the solution to describe collaboration between the components in the making of telephone calls. I had to sell both the problem (since it was unknown) and the solution. The idea was very controversial so that it succeeded was a mere miracle.

In 1986, Use Case was the solution to the problem that traditional functional specifications were immense and not testable. To start from the users and find their different use cases made the specifications understandable, while we also at the same time found the test cases. The result was a good way to do test-driven development, now being popular in agile teams.

First developed in 1978 and then further developed in 2005, Aspects were the solution to the problem to avoid changing what already works just because we want to add new features. It became a book and many large companies have embraced this, but it will take some more years to go before it will become the standard way of working.

Intelligent agents were, in 1981 and later in 2000, the solution to the problem that 80% of what we do when we build software is repetitive no-brain work.  When we develop something we follow patterns we have followed many times before. Having qualified resources just following standard patterns is not smart.   We built Waypointer, but at a too early point of time. The idea will come back in some years.

In 2003, Practices became the solution to allow many methods in a company but still have governance – enough governance, but no more than necessary.

Over the years there have been some ideas. But it is not enough to come up with new ideas. You must always show how to implement the ideas. Thus I designed the first two components at Ericsson. And in my business, I have driven the ideas into products. This also requires perseverance. You must not give up just because you meet good but tough resistance.  Actually, every good idea will meet substantial resistance.  If it doesn’t, then it probably is not a new idea.  However, don’t make the mistake and interpret every idea that meets resistance as a good idea J.

Moreover, many times my solutions had no support in existing technologies, such as no support in existing programming language or operating system. For instance, when I came up with components in 1967, there was no support for signals and interfaces in the assembler we used.  Thus, I had to come up with a solution that simulated these language constructs.  In working with my colleagues we came up with the idea that every signal was implemented by a macro owned by the receiving component.  Sending a message was thus implemented as calling a macro.  That was smart.  Similarly, when we did aspects we had to find a smart way to extend code without changing it.  This mechanism is today called pointcuts.  When we created Waypointer there was no support for object-oriented agents, so we had to simulate that.  Your ideas may not be supported by your platform, but don’t let that discourage you from implementing your ideas.

Thus, as a summary, what drives me is to make the people I work with successful. To achieve this, I invent new ideas, all of which come in pairs – a problem with a solution. Almost always, I have been selling both the problem and the solution. And, no idea has sold itself; you must always contribute to its implementation. It requires stamina.

I hope that you dear readers might learn something of this. Maybe that would be Smart!

  1. Carlos Barbieri | October 5, 2010 at 5:56 pm Reply


    Mr Jacobson, good evening,
    I have been working with use cases for long long time, as well as with BI(Business Intelligence). Now i am thinking about a way to connect both! BI-UC(BI Use Case). I know that the first is ” data driven” and UC is “process driven” and, in my opinion, there could be “back-end use cases” and front-end use cases.The first would take care of ETC functions and second of BI-applications. Do you think those concepts are like oil and water? I don´t. Thanks Carlos Barbieri

  2. Philippe Back | August 26, 2010 at 3:00 am Reply


    Words of wisdom. Maybe because they resonate so much with my own ways (albeit not at your scale)!

    Key takeovers:

    1) find the problem and half of the work is done
    2) an idea = a problem + a solution
    3) show how to implement an idea otherwise, there is no point
    4) my business is there to drive ideas into products (or leverage combinations of existing ones, so I would rather say “into solutions”)
    5) practices = allow many methods in a company but still have (essential) governance.