News

Interview with Ivar Jacobson

Founder and Chairman, Ivar Jacobson International

See Russian translation of this interview: https://habrahabr.ru/post/336782/.

What inspired (and hopefully still inspires) you personally to create everything you actually created or participated in creation: RUP, UML, EssUP, EssWork, SEMAT?

What inspired me? … I think it was that I hated to see situations where people spend a lot of their passion, energy and time working hard, night and day, doing, let me say, things not so smart… And the first thing I changed was when I was a young man in 1967. I was a project manager for the development of the most mission-critical system at Ericsson in Sweden. We developed at that time the first computer-based telecom switching system. And as a project manager I felt very soon that the way we developed the software was very immature. At that time we had one big program store and one big data store. The approach we used was a commonly used approach at time. It was really not an efficient approach in building a system that had to change all the time. So, I suggested what today we call component-based development, which means that we build the whole systems with interconnected components. To get that approach accepted I had to go through the biggest fight I’ve ever had in my life. Because no one wanted to do it. The programmers didn’t like it, their managers didn’t like it. There was only one man, who liked it. Thanks to him being the boss, he decided that we should do it. And that resulted in the greatest commercial success story ever in the history of Sweden, and it still is the greatest commercial success story in Sweden. Even more successful than Volvo, ABBA and so on.

So that’s how it’s started. I could not stand to see all these fantastic people working in a bad way. And for the same reason I came up with use cases, I couldn’t see the complex way we dealt with requirements. And I continued later on with RUP and what became UML. There were similar reasons behind it.
Similar reasons drove me to find a common ground for software engineering methods and practices. I started working on what became the OMG standard Essence 13 years ago. It took us 10 years to get there, but now eventually I see successes.

In your opinion, what is today’s main problem in the field of software development?

The biggest problem is that we don’t really have a common understanding of what it takes to develop software. We have very poor education in how to build commercial software. We are really good in computer science, we are good in developing languages, operating systems and basic technology. But we are very poor on science of how to build commercial applications. We have many great companies building fantastic products, but the products are the result of great ideas and great people, not because of an underlying science in software development. We have also many good practices in how to develop software, in particular now in the agile era, but in general they don’t stand on any solid theory that allow us to continuously improve them and predict the outcome of using them.

People develop software around the world but in general the quality is poor, it takes a lot of time, and it is too expensive. We really take too long to educate people and it is hard to get competent people, etc…
The bottom line is that we don’t really have a common understanding of what software development or software engineering is. That I think is the biggest and most serious problem today. People spend a lot of time on doing things that are actually not very difficult or smart, instead of reusing knowledge. Reuse of knowledge, reuse what it takes to develop software, is the most missing thing as I see it. And that is what the SEMAT community is addressing at its core.

So SEMAT helps to solve these problems?

Yes, the first real outcome of SEMAT was the Essence standard in 2014. Essence is basically a common ground. It describes the essential things to have, the essential things to do, the essential competencies to have when developing software for any kind of today known software. It is a vocabulary, but it also allows teams to measure progress and health while working on an endeavor.

This common ground is now being used as a platform to describe many different practices such as Scrum, user stories, use cases, continuous integration, …microservices, cloud practices, etc.. Essence includes a very simple and intuitive language to describe practices, so it is extremely easy and fast to describe a practice this way. Then there is an additional benefit using the Essence language: these practices can in a very efficient way be composed into methods. This is very smart, because the number of practices we have today are just a few hundred, but they can be composed into an almost infinite number of methods.

To get back to the issue of reusing knowledge. In the past we have done this poorly. We “borrow” ideas from people out there, but we have no common eco-system where we can take well-proven, well-described, easy to read and use practices. SEMAT addresses that problem. We are now building libraries of practices, where teams and organizations can find reusable practices and select the ones they want or need and compose them to a balanced way of working. There are tools allowing people to do that and to make improvements when more experience is collected. We get true reuse of knowledge!

Who or what was your most valuable influencer in your entire life?

Several people have had huge impact on my work life.
My first boss at Ericsson, Jan-Erik Nordin, taught me 1964 to think about design on a more abstract level than physical design and he did that for electromechanical systems (systems built of relays and not computerized). I understood how systems were built of physical components and how important it was to define the interfaces between the components so it would be easy to later replace a component with a better one. This experience I used later to come up with components entirely built in software.

Later in 1978 I met professor Dines Bjørner from Copenhagen. He opened my eyes for the importance of formal methods, in particular for how to formally define a language. I used this experience in our work on UML and now lately on the Essence language. We defined the abstract syntax and the static semantics formally, but we felt that for practical reasons the operational semantics had to be done in just precise English. Once I understood the value of formal methods, I apply a more precise thinking to everything we do than what I would have done otherwise and it helps us to be better understood and appreciated among experts.

Finally professor Dave Thomas from Carleton University in Ottawa very forcefully made me an early adopter of agile ideas. It helped me to rethink how to work on methods. Instead of trying to be complete as we were with RUP, we decided to focus on what was essential (less than 5% of being complete). We needed a new user experience in working with methods, which resulted in using poker-sized cards to present practices – easy to understand and use. Finally, we wanted to empower the teams to easily select their own methods, which resulted in the common ground Essence and practices in a widely available practice library.

What would you deem as your most important contribution in your entire life?

It’s hard, someone else than I should do this 🙂
However, I have been thinking, Ericsson was a big company, they had in 1967 several hundred software developers. I have many times asked myself the question ‘Why? Why did no one else come up with component-based development? And why was it so hard to convince the rest of the organization that we should do component-based development?’ And ‘What’s wrong with me when I fought against everybody about what I believed in, why didn’t I give up’. If I would have given up it would never have happened at that time, it would have happened later but not at that time. Then the same question why did I came up with use cases, why no one else? Why did we develop what became the most popular methodology back 20 years ago – RUP, and so on. It’s hard to judge, but I think introducing component-based development was probably the most important thing I’ve done. It resulted in self-confidence and in coming up with more ideas.

Looking back into the past, what would you change if you had a chance?

I got this question at a very big conference with about 2,000 people in the audience – I think it was 1995. It was at a panel discussion at an OOPSLA conference somewhere in the United States. There were 5-6 people in this panel; most of them said there is nothing they would have done differently. But when the question came to me I said there are two things I should have done differently both inspired by my friend Dave Thomas. Dave and I were in 1988 sitting out at my country house in the Stockholm archipelago. Dave suggested, ‘you should write very simple book, 150 pages, and only about use cases. It will be a market leader, a book that everyone want to read.’ However, I said, ‘No, no, no, no. Software engineering is too serious to write a 150 page book about.’ Now in hindsight I should of course have followed his advice. The other thing he suggested, ‘You should let me do a tool to go with this book; I will do it to you for $100,000’. However, I responded, ‘It’s a too simple tool. This is engineering, this is more advanced, I want to have a real tool.’ So, I developed a tool that cost in the first release something like $1,000,000. So, these two things I should have done differently, it showed that I didn’t understand modern marketing, etc. That was my answer in 1997, and it is still my answer.

You have written several books, do you plan to write a new one? If so, what will it be dedicated to?

Yes, there is a new one – Software Engineering Essentialized. It is in draft shape now. I have since two years been working with four other people on this book. We have created a project with about 50 people from around the world, including some from Russia, to develop training material and exercises for the book. These people are reviewing the book right now. After updating the book based on the review comments we will publish the book. This book is for first year university students – people who never developed any real software, only written some small programs.

Your last SECR presentation was called “Agile and SEMAT – Perfect Partners”. What are your plans for SECR 2017 keynote?

I thought of a talk titled “Kill all Methods, Free the Practices”. Methods here refers to branded methods. We really don’t need any branded methods. We need to create our own method from reusable, well-proven practices.

Do you remember the very first SECR in 2005? If yes, could you share your impressions in comparison to your last visit to SECR in 2013?

I think the first conference was very different from the one we were at last time. I felt it was quite immature. The talks were not the same kinds of talks which we had at other international conferences, they were more academic maybe. But the conference in 2013 was very similar to big conferences in United States and Europe. It adopted subjects which were practical. It was more for developers and less for the academics compared to 2005.

Have you been in St.Petersburg?

I was many times in St. Petersburg. First time in 1961!

You saw how the city changed.

Definitely. In so many ways. I studied at Chalmers Institute of Technology and after the third year we went on a study trip. Usually these trips went to south Europe, but this year we went to the Soviet Union. During the trip we had KGB agents around us all the time. People we met were later interrogated about what we discussed. Very interesting for us because we couldn’t believe something like that could happen. Today going to St. Petersburg is from this perspective like visiting any other big city in Europe.

You have been working very efficiently for a long time. What is your personal secret of staying so active?

Having fun! 🙂

Thank you!