[Interview] Ivar Jacobson: Fed Up With Talking About Processes

Jan 25, 2008
Tomonori Shindou, Nikkei Electronics
Ivar Jacobson, one of the "Three Amigos," who developed the UML
Ivar Jacobson, one of the "Three Amigos," who developed the UML
[Click to enlarge image]
The flow chart of the development of EssUP (from Jacobson's lecture materials)
The flow chart of the development of EssUP (from Jacobson's lecture materials)
[Click to enlarge image]
Practices in the EssUP (from Jacobson's lecture materials)
Practices in the EssUP (from Jacobson's lecture materials)
[Click to enlarge image]

"I believe all software engineers do not like to talk about processes," said Ivar Jacobson, one of the "Three Amigos," who developed the UML (Unified Modeling Language). "Sometimes, heavy processes crush engineers. I am fed up with talking about processes."

Jacobson is an outstanding figure in the field of software engineering. When he was a software engineer for Ericsson of Sweden, he came up with the concept of "use case," a sequence diagram and a collaboration diagram. After that, he quit Ericsson, founded Objectory AB of Sweden and put together and advocated OOSE (Object-Oriented Software Engineering), a software development methodology based on the use case.

After Objectory was bought by Ratioal Software Corp of the US, Jacobson developed the UML, a notation of software models, with James Rumbaugh, Grady Booch and others. Also, when he worked for Rational Software, he participated in the development of the RUP (rational unified process) based on "Objectory Process," which he developed in Objectory.

Jacobson has been leading the field of software engineering. And now, he flies around the world from one software development site to the next as the chairman and CTO of Ivar Jacobson International of Switzerland, a consulting firm he founded. I asked him about his current activities and the prospect of software engineering when he came to Japan to deliver a lecture. (Interviewer: Tomonori Shindou)

- You are claiming, "There is no need for big processes like the RUP."

When I started to work for Rational, we had a process named "Objectory Process." Objectory Process is simpler than the RUP. In that sense, the RUP ended up being too heavy.

In the 1990s, we developed the RUP in Rational and sold that process to other companies as a product. We sold the 1,500-page book at as expensive as 22,000 US dollars, probably the most expensive book in the world. But we sold 600 copies in total though our sales goal was 1,000 copies. ...

However, people do not read thick books thoroughly, especially books about a process. In the end, I had to fly around the world and explain it in person because they do not read books. For example, CMMI process improvement is flourishing in India. But I could not find any engineers who like processes even in the Indian companies when I visited there. The RUP is not a bad process, but it is too enormous.

- Is that the reason why you developed a lighter and simpler process "EssUP (essential unified process)" in the current company?

That's right. After founding Ivar Jacobson International in 2003, we developed the EssUP, a simpler process. The EssUP, different from the RUP, is free. The approach that I came up with in Ericsson developed into Objectory Process, and then it became the UP (unified process), RUP and finally EssUP.

There are not many totally new concepts in the field of software engineering. The important thing is how to simplify them. As for processes, it is not necessary to write down everything about the development, but its essence is most important.

When I developed the EssUP, I knew well that people do not read thick books. So, for the EssUP, I decided to use cards, not a manual, so that they feel comfortable learning processes. For the EssUP, we prepared five technical practices, "architecture," "iteration," "use case," "component" and "product," in addition to three cross-sectional practices, "process," "team" and "modeling."

The important points of these practices, which are necessary to develop softwares, were briefly summarized on 5 × 3 inch cards. You do not have to use the processes that you do not need, and you can add cards by yourself.

Those cards are especially useful for lectures and workshops. But they can be lost when used for actual software development. That's why we prepared a tool named "EssWork," a framework to help learn the EssUP. This is also free and has already been adopted by some major companies in Japan.

- When did you realize that heavy processes are not necessary?

Processes are no longer essential. They should be considered as the by-products of intricately-intertwined practices. Practices here mean methods and devices to solve and approach various problems of software development. For example, they are iterative and incremental development, use case driven development, pair programming, team practices like workshops and so forth.

These practices naturally exist in the organizations that develop softwares. However, they have not been sophisticatedly expressed so far. In about 2000, when agile methods like XP began to be recognized, the idea of combining several practices and using them at the same time was finally recognized. The approach of "using cards" adopted in the EssUP came from the "story cards" of XP.

I came under the great influence of agile methods. When XP appeared in 1999, many people said, "XP is not important. It's no more than a pair programming." At that time, I publicly declared, "XP will be a serious threat to the RUP." But few of them understood it.

I became keenly interested in agile methods in 2003, when I quit IBM and founded Ivar Jacobson. In August of this year, a conference named "XP/Agile Universe 2003" took place in New Orleans, the US, and I attended it for the first time.

There are many schools of agile methods such as XP and Scrum, as you know. There are some common points like "the adoption of light processes" and "the focus on social engineering" and some differences among the schools. But all of them have one thing in common: All agile methodologists dislike the RUP.

- What is the role of an agent technology "WayPointer" in the EssUP?

Eighty percent of the tasks in software development are mindless routines. I have some experience of them. In this kind of situation, WayPointer helps develop softwares with an agent on the computer.

Complementary explanations for each practice are provided by a "guideline" of a few pages in addition to the cards. But WayPointer further guides developers in each phase of the development. Tata Consultancy Services of India enhanced its productivity by 20% in the analysis phase by using WayPointer.

WayPointer is a pay product. Though it is not indispensable for practicing the EssUP, it can effectively establish processes. WayPointer was developed by Jaczone AB, which I founded. And Ivar Jacobson International bought out Jaczone in April 2007.

You evolved the use case driven development. And now you are advocating for use case-driven aspect-oriented development. Do you have any examples in Japan?

Yes, there are some examples. One of the examples that I can tell is the development of embedded software for Sony's car navigation systems. As for aspect orientation, "AspectJ," an aspect-oriented programming (AOP) language, is famous. But aspect orientation is very effective not only in the mounting phase but also in the phases of analysis and design.

When a design based on aspect orientation is being coded, an AOP language like AspectJ is useful but not indispensable. In fact, in the case of Sony's car navigation systems, a conventional programming language is used.

There are many "cross-cutting concerns," such as security, involved in software development. And it is very, very advantageous to separate and mount them as "aspects" because it enables to change their behaviors by "hooking" them without changing the objects themselves at all. The farther of AOPs, Gregor Kiczales, dealt with only a part of numerous aspects.

In the explanation of OOSE, I mentioned the concept of "extension use case," which means to extend an existing use case without changing it. This is very similar to an aspect in aspect orientation.

I heard you have a plan to build an office in Japan

We are now preparing to establish it in 2008. I understand that Japan is a very difficult market because the managers of Japanese companies tend to stick to traditional processes and methods. We send consultants from our branch offices around the world, like in Singapore and Canada, to our customers in Japan such as the car navigation development team in Sony.