Interview with Ivar Jacobson, founder of UML, RUP, Essence

Ivar Jakobson, almost a legend - the founder of UML , RUP , SEMAT - restless, continues to try to restore order in the software development industry. And to the question: “What helps to remain so active?” Answers: “Having fun!” :)

We offer the reader a translation of an interview with Ivar, which he gave on the threshold of his autumn trip to St. Petersburg to the organizers of the SECR conference.

What inspired you (and I hope, still inspires) to create and participate in creating RUP, UML, EssUP , EssWork, SEMAT?

I think the fact that I can not stand when people spend their energy, fuse, work day and night, while doing, I'm sorry, not very smart things. And the first thing I changed when I was young, in 1967. I was a project manager in a very important system development team at Ericsson in Sweden. At that time, we developed the first computerized telecommunications switching system.
')
I very quickly realized that the existing way of developing software is not perfect. We had one big program repository and one big data repository. This was a very inefficient approach to building a system that had to be changed all the time. And I proposed what is today called component development, which implies that we build all the systems using interconnected components.

In order to adopt this approach, I had to face the strongest resistance in my whole life. Nobody wanted to do that. Programmers and their managers did not like it. There was only one person who approved of the proposed approach to software development, but this was our boss, and he decided to implement his plan. As a result, we received the greatest commercial success in the history of Sweden. Even more successful than Volvo, ABBA and others.

That's how it all began. I could not look at how all these wonderful people work inefficiently. And for the same reason, I unexpectedly came up with the idea of ​​use scenarios (use cases). I could not observe how unwisely we work with requirements. Later, I continued working on RUP, and then UML. There were similar reasons behind this, which led me to search for common methods and practices of programming. I started working on what became the OMG Essence standard 13 years ago. It took us 10 years to do this, but today I see success.

In your opinion, what is the main problem in software development today?

The biggest problem is the lack of a common understanding of what software development involves. We do not teach how to create commercial software. We are good at computer science, in the development of programming languages, operating systems and basic technology, but we are completely unable to create commercial applications. We have a lot of great companies developing great products. But the products are the result of great ideas and great people, and not a sophisticated scientific base in software development. We have a lot of good development practices, especially now, in an era of flexible methodologies, but, in general, they are not based on any solid theory that would allow them to constantly improve and predict the results of their application.

People develop software around the world. Unfortunately, in general, it is of poor quality, has been developed for a long time and is too expensive. Indeed, we have been training people for too long, and it is difficult to get competent specialists, etc.
The bottom line is that we really do not have a common understanding of what software development or software engineering is. And, in my opinion, this is the biggest and most serious problem today. People, instead of reusing knowledge, spend a lot of time doing things that are not very complex or smart. The reuse of knowledge, the reuse of what is required for software development, is the most missing thing. And this is precisely the main message of the SEMAT community.

So SEMAT helps solve these problems?

Yes, the first real result of SEMAT was Essence in 2014. Essence is a common ground. It describes the main things that need to be done, the basic competencies needed to develop any modern software. This is a “dictionary”, which also allows teams to measure the progress and status of the project in the process.

This common framework is currently used as a platform for describing many different practices: scrum, user stories, use cases, continuous integration, microservices, cloud technologies, etc. Essence includes very simple and an intuitive language for describing practices with which they can be quickly and simply described. Another advantage of using Essence: these practices can be quite effectively put together in a technique. This is very clever, because today we have hundreds of practices that can be put together into an almost infinite number of methods.

Let us return to the question of the reuse of knowledge. We used to do it badly. We borrowed ideas from people, but we didn’t have a common ecosystem where we could use well-established, well-described, easy-to-read and applied methods. SEMAT solves this problem. Currently we are creating libraries of practices that teams and organizations can use by selecting the right ones and combining them for balanced work. There are tools that allow people to do this and improve practices when experience accumulates. We get really reusable knowledge!

Who or what has affected you the most in life?

Several people have had a huge impact on my work-related part of my life.

My first executive at Ericsson, Jan-Eric Nordin [Jan-Erik Nordin], in 1964 taught me to think about design on a more abstract level than physical design, using the example of electromechanical systems (systems built from relays, not computerized). I understood how systems are built from physical components, and how important it is to determine the interaction of [interfaces] between components, so that later you can easily replace a component with a better one. I used this experience later on in components that are fully embedded in the software.

Later, in 1978, I met Professor Dines Bjørner from Copenhagen. He opened my eyes to the significance of formal methods, in particular, how to formally define a language. I used this experience in our work on the UML, and more recently in the Essence language. We formally defined abstract syntax and static semantics, but felt that, for practical reasons, operational semantics needed to be done definitely only in English. Since I understood the value of formal methods, I have applied more precise thinking to everything I do, and this helps to be understood and appreciated by experts.

Finally, Prof. Dave Thomas of Carleton University in Ottawa. Thanks to him, I was one of the first to introduce flexible methodologies into the company. It helped me rethink the work on methods. Instead of trying to make them final, as we did with RUP, we decided to focus on what was most important (less than 5%). We needed a new user experience with methods, which resulted in playing cards the size of playing cards representing practices that are easy to understand and use. As a result, we wanted to give teams the opportunity to easily choose their own methods, and this led to Essence basics and a widely accessible library of practices.

What do you consider your main contribution?

It is difficult, someone else, not I have to tell you about it. :)

However, I thought about it. Ericsson is a big company, in 1967 several hundred programmers worked there. I asked myself many times the questions: “Why did nobody come up with component-based development? Why was it so difficult to convince others in the organization that we need to promote component development? What is wrong with me, since I fought with everyone for what I believed in and why I did not give up? ” If I had given up then, nothing would have happened at that moment — it would have happened later, but not at that time. And also: “Why did the usage scenarios come to my mind, why not to someone else? Why did we develop what became the most popular methodology 20 years ago - RUP? ”- and so on. It is difficult to judge, but I think that the introduction of component development was probably the most important thing I did. This led to self-confidence and the emergence of new ideas.

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

I was asked this question at a very large conference in front of an audience of about 2,000 people. It seems that this was in 1995 at the panel discussion of the OOPSLA conference in the States. In our group there were 5-6 people, and almost all said that they would not change anything. But when it came to me, I said that there were two things that I should have done differently, and my friend Dave Thomas inspired me both. Dave and I were sitting in my country house, Dave suggested: “You have to write a very simple book, 150 pages and only about use cases. The book will become the market leader, everyone will want to read it. ” And I said, “No, no, no, no. Software development is too serious to put in 150 pages. ” Now, looking back, I certainly would follow his advice.

Another thing he suggested: “Let me create a tool with this book. I'll do it for 100 thousand. " And I replied: "This is too simple, immediately advanced engineering, and the tool also needs advanced." So, I developed a tool that cost about 1 million dollars in the first version.

These two things, which I would have done differently, showed me that I did not understand marketing then, etc. So I responded in 1997, and this is my answer so far.

You have written several books, are you planning to release a new one? If so, what is it about?

Yes, the new book, Software Engineering Essentialized, is still in draft form. We worked together on it for about two years, we also created a project with about 50 people from around the world, including Russia, to develop training materials and exercises for the book. Now these experts are checking it out, and after updates based on their comments, the book will be published. It is intended for first-year students - people who have never developed any real software, but have written only a few small programs.

Last time at SECR you talked about Agile and SEMAT - Perfect Partners. What are your plans for SECR 2017?

My report will be called “Kill Methodologies — Free Practice.” I mean “branded” methodologies: in fact, we don’t need anyone’s “branded” methodologies, we need to create our own method from those practices that have been used repeatedly and have proven themselves.

Do you remember the very first SECR 2005 conference? If so, can you share your impressions from your last visit to SECR 2013?

I think that the first conference was very different from the last one: then it was still young, the reports were not the same as at other international conferences, they were more “academic”. And the conference in 2013 was very similar to the major conferences in the United States and Europe. It dealt with practical topics. It was more for developers and less for scientists in comparison with 2005.

Have you ever been to St. Petersburg?

I have been to St. Petersburg many times. First time in 1961!

So you saw how the city has changed.

Definitely. IN many respects. I studied at the Chalmers Institute of Technology, and after the third year we went on a student trip. Usually these trips were to southern Europe, but this year we went to the Soviet Union. During the trip with us were always KGB agents. The people we met were later interrogated about what we were discussing. We were very curious about this, because we could not believe that such a thing could happen. Today, a trip to St. Petersburg is like visiting any other big city in Europe.

You have been working so effectively for so many years. What is your secret?

Enjoy! :)

Interview: Anfisa Letucheva.
Translation: Yulia Kryuchkova, Anna Gorbatenko (translation corrections are absolutely welcome :). Original interview: Interview with Ivar Jacobson .