Cloud Hosting

Subscribe on:ApplePodcasts Google Podcasts Soundcloud Spotify Overcast Podcast Feed Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I have the privilege of sitting down again with Ivar Jacobson.

Ivar has been a guest on the podcast before, and is one of the stalwarts of software engineering. Ivar, welcome. Thanks for taking the time to talk to us today.

Ivar Jacobson: Oh, thank you. I really appreciate the invitation. Thank you.

Shane Hastie: I mentioned that you're a stalwart, but perhaps for some of our audience, they might not have come across your work before, so do you want to give us a brief overview of, who is Ivar Jacobson?

Ivar Jacobson: Well, yes, I will be happy to do that. I didn't know I was interested in methodology when I was 28 years old and worked at Ericsson, and became project manager for our most mission-critical project at that time. It was a computer-based telecom switch. The methodology people used, even if it didn't talk about the methodology, was very close to what the many methods were at that time, separating functions from data.

We had a big data program store, where you put in the functions, and you had a big data store where you put your data, and you developed a program separate from the data. My job was to make sure we built the product that could be marketed around the world, easily adapted to new requirements. And thanks to having a hardware background, I understood what they were doing was really not working, and would never work. I said they, I mean the development team; it was 70 people, or something like that.

As a project manager, I shouldn't put my fingers in that. I should run the project, and the method was already set in stone. It was the intention. But as a bad project manager, I couldn't keep my fingers away from how to do it. So I came up with a way that we now classify as component-based and that resulted in success.

Ericsson was the only telecom vendor that we used that approach and they won everything, but it took 10 years before people at Ericsson knew it. But then I was awarded to get the PhD during work hours. I spent five years doing nothing for Ericsson, only get the PhD. That was very educational because now I started to understand how a computer worked too. Well, a little bit exaggerated. And that was late of my part of my life.

I always was involved in methodology work and I had great interest in it. So they sent me to standardization and we created a modeling language in this standard group that is the predecessor to UML and that was the biggest competitor to UML when UML came out in 1997. So in 1980 say, this telecom standard was adopted and almost 20 years later UML came. And it is very similar languages in some aspect, in other aspects, not.

After my PhD, I set up a company and we developed what later became Rational Unified Process because Rational acquired us and because of what we had and Rational Software grew dramatically. I was there with two other gentlemen, Grady Booch and Jim Rumbaugh. We were nicknamed the Three Amigos and traveled around the world talking about what we had done together, namely Unified Modeling Language and later also Rational Unified Process, which came from my company in Sweden.

That went well until Agile came. Agile just killed first Rational Unified Process; it took only a couple of years, also UML, no one would do modeling anymore. By the way, all that is coming back. It's all coming back and this is what has happened in the history of software engineering. It all comes back. The good ideas come back. And at some point, in time I also came up, it was called use cases and use cases became really the thing that was adopted all around the world.

But that also because it belonged to the old generation so to speak, it was also thrown out and replaced by a simpler approach, user stories, and that's it. Now we are about around 2005 or 2000 something. I have always been interested in artificial intelligence. So in 2000 I founded a company, actually with my eldest daughter, and we developed a product to support software development. So we had copilots, we call them developer assistants.

We used AI technique called intelligent agents and we got a Jolt Award in 2003, if I remember correctly, for one of the most interesting products at that time. At that time, I also was fed up with methodologies to be very honest with you. Methods was just a number of problems. We have methods war, so good people were fighting with one another which had the best method.

We created sects around every method, there were people that loved that method and talked about that method and talked bad about other methods. And you couldn't use... For instance, many people want to use use cases with their method. So they tried to take cases from my method and put into their method, but since they were totally differently described it became not really successful.

So I said that methods put good ideas into prison, namely their own prison. So you couldn't take them or use it at other place, but many problems like that.

So I decided enough is enough for me. We had a new method coming out that was agile and would very well compete with the methods we see today or popular methods like SAFe for instance. Nothing bad said about SAFe, it's probably one of the better if you talk about these full scale methods. But we selected another path. We decided we want to find what is the common ground of all these methods, what do we share? They must share something. They all use the software; all for product development engineering. So we created such a common ground, Essence, and it became an international standard.

And since then we have worked on popularizing it. We have come a very long way, but that's a very different story.

Shane Hastie: There's a lot there. The classic tool of requirements representation coming out of your work is the use case. So a sequence of interactions, a flow of interaction between a person and a system, a tool to represent and communicate the requirements. But one that seemed to, and you alluded to it there, they seemed to go out of favor.

What happened there?

Ivar Jacobson: Yes. When Agile came starting with extreme programming around, let's say, at the beginning of 2000. The Agile movement basically killed any old approach and they were more focused on how people work together, basically social engineering. Agile didn't really introduce any new technical practices. You can say that iterative development using sprints and working in small periods to deliver concrete results was already there. It was used since the early 1980s. There were scientific work around the spiral model of development by Barry Beam.

So it had been around and my own work and the work that we did at Rational Software at that time was definitely iterative. What has probably happened, has happened, is that iterations are short, sprints are shorter than it were at that time. At that time they may a month, now they're down to days, but the idea is basically the same. And then the technical practices you can mention user stories as one of these technical practices.

It was focused on small things that a team could do in such an iteration or sprint. So Agile flirted with the developers, the people really did something of useful value. Whereas in the old days, I must confess, we flirted, if I use that word, the more system engineers as higher level people, not the programmers directly.

We felt that a lot of code is done in modeling. You identify the components, you identify the interfaces without writing a line of code, but of course, you need to understand how it is going to be implemented. So there was a switch that made the majority of developers feel they got support from the methodology, they got support from the Agile way of thinking, and we were the old dinosaurs and everything that we had done was just rubbish, get it out. And that was, of course, something I understood very early.

So I didn't want to continue create a new dinosaur or something that people would call a dinosaur, whatever it was, so we did this common ground instead. But when it comes to use cases, use stores was a really great contribution. I remember when I met Kent Beck who was one maybe the key originator of the user stories at the conference and I went over to him, he was signing books and I said to him, "Congratulations, Kent." I'd known him for many years at that time, 10, 15 years, and actually I'd invited him to come to Sweden and teach and so on, small talk action to my people.

So we were congratulated him and he said something, a compliment back, "Well inspired by use cases," or something like that. So these two things should never have been seen as in conflict. They were extremely good compliments to one another because use cases deal with a bigger picture.

You can, in a couple of hours, present a model of the system in the form of say 20 use cases and everyone will understand what the system is going to do. Of course, to go deeper, you require more thinking, but to get the big picture very quickly. And use case also is language where people talk about from a business perspective. For instance, I don't know any modern product that doesn't talk about which use cases does this product have. And you see it also in normal English. So it has become a normal English word, use case. And if you Google it, you will find maybe a hundred times more hits than you find on user stores. I don't know really, but it's dramatic difference.

So there is a value in use case thinking that help you to understand the big picture of a product. You may have 800 user stories but only a couple of use cases, maybe 10 use cases. And so you get a really good picture of what the system is doing. And people do use cases, they have done it all the time, particular business analysts, but then they have a problem to communicate with the developer team because we don't want to hear about use cases, we want to hear about user stories. And this is what has gone on for now many years, 20 years or so. But we are going to change it.

Shane Hastie: Use cases definitely are... We are seeing a reassurgence, but I'm also seeing that there's something different about the way you and people like Alistair Coburn are talking about use cases today compared to what were. I will confess to having seen some pretty appalling use cases in my time.

One that springs to mind was an author who tried to write all of the functionality for a complete ERP system in a single use case. It ended up 127 pages and a week later even the author couldn't tell us what it was. Now that in my experience, is the extreme example of a really badly done use case.

Ivar Jacobson: Yes, absolutely. When I started with use cases, I developed one way of using use cases; we call it use case driven development. So it's not only for requirements. A use case was also something you realized. So for every use case we identified, we describe how to realize it as a collaboration among components with messages and so on. We use diagrams, very popular diagrams, they still popular, sequence diagrams. They are actually popular, but you describe how components interact to do something.

And then use cases with test cases. So once you understood the use case, you could direct it from a use case, identify a huge number of test cases, a big number of test cases. So use cases, we had a very big picture for them. Of course, we used them also only for requirements, but that was then simpler use cases. So we learned was that it can be used in so many different ways.

If you develop life critical systems, you have requirements on more details, level of detail. If you write for instance a business application or website or something like that. So it's not one use case that is needed for people about many different variants. Alistair, you mentioned Alistair, he came to Sweden and learned about use cases. He felt it can be done better as natural and of course it can be done better, so he started to work on a different way of doing use cases.

The value of that is that more people talked about it. He has definitely contributed a lot when it comes to popularizing use cases. He introduced a goal structure, so a goal has sub goals and sub goals have sub goals and so on, all the way down to very small things and many people like that and it's fine.

So you mentioned bad use of use cases and I've seen similar application of use cases that I've immediately said this is trying to do too much. People have loved the concept and tried to use it more than is proper.

So what we have done now recently, I have been thinking personally for a couple of years and worked with some people on what we called use cases need to come back. We had a plan for a campaign but I said no, this is not enough. We need to get the more people to stand behind it. So I saw an article of Alistair, it probably was a LinkedIn article where he said basically that use cases are needed and I contacted him and we decided to write the paper together.

So that's how we started now probably eight months ago or something like that. We wrote the paper together and writing papers together when you sit far away and don't have an immediate contact is not an easy thing, but it went very well. I had a colleague in my company who started off with a proposal, Alistair took it and said, "No, no, no, this is not how I want to write it." So he wrote a completely new, we decided that it's close enough. With some modifications, we had a paper and it was published in ACM Queue in September, October of last year.

So that was our first step towards doing something together.

Shane Hastie: What does a good use case look like today?

Ivar Jacobson: It depends. I'll tell you one thing it does, it follows, we could call it the foundation. So Alistair and I, we have written a paper together, together with actually Ian Spence who has been working with me for, I think. Almost 20 years and is really a use case expert. And we have written a paper together which is called Use Case Foundation. It includes a definition of use cases. I mean, just having a clear definition that we all can agree on what is a use case was a good thing.

Now, if you ask me to tell you what is use case, I have to think a little, but it is basically all the ways to use a system. It's very important. It's a system that owns the use case. So it's all the way to use the system to achieve a particular goal for a user.

Maybe very some word here that I have got wrong, but it's basically what it is. It's super critical. But there is an entity for which the use case belong. Use case is all the ways of using it. All the ways meaning if you do a particular use case, there are many different paths you can follow, success paths and alternative paths and failure paths. So all these ways to use the system to achieve the goal for a particular use or something like that. And that's a very good start. And then there is other things in this use case foundation document like principles that we think are important to obey and also some patterns.

It's not a thick document, I think it's four pages, but it gives a really good foundation. The idea is that people, not only Alistair and myself or my people, will use this foundation and then describe our different ways we can create use case practices, how we can practice use cases.

And Alistair is working on a book now and we also working on a kind of book, but it's not a thick book. It's a very thin book, maybe 50 pages, maybe something similar to the SCRUM guide when it comes to use cases. It'll describe a family of use case practice, not only one. So for instance, one practice we call use case storytelling, which is a very simple practice that works very well. For instance, web development, just to take an example. And then there is another called use case visualization or something like that. I don't know the names in detail. Well I don't know exact wording, but it's about visualization. This is where you can use diagrams. For instance, many typical products require much more detail about the use case that you need for developing a website. So they use, for instance, activity diagrams, they use swim lanes to describe what is done by the user and what's done by the system and sequence diagrams.

So a whole bunch of diagrams you can use. So these are the basic stuff. On top of that, you can have use case offering, which is more advanced than use case storytelling. And when it comes to the modeling side, you can have use case modeling and that means you make, for instance, a model of all your use cases and give basically a design of the use cases. Use cases are not design, it is a specification, it's requirements. But you can get very good complete picture of what the system is supposed to do by just looking at such a use case model.

And there are more and more advanced and we have six such practices we are just now working on and they should be presentable in a couple of weeks I will say.

Shane Hastie: So at a fundamental level, I suppose I want to explore what is different today about these use cases and the range that you're talking about to what we were working with when you first came up with these.

Ivar Jacobson: Yes. So in the first version, let's call it use case 1.0, we identified iterations and we started to work with the most critical paths in every use case. So we didn't take one use case specifying it completely at once, and then we went to design it and code it and test it. No, that is what the people who wanted to kill us said we did, but it's never true. We can go back to the original book from 1992 and it's very clear we develop in iterations and we don't develop complete use cases. So what we did is we took a path through use case. These paths could very well be described as a user story today or many user stories, such a path. We didn't have that term, but that is how we were thinking. Now people didn't feel like that. So in that sense, the Agile movement were right, people did waterfall, people did sitting and doing all the use case models.

And when we did a lot of modeling, we did too much modeling of the system. I mean I remember I worked with one bank, big bank in the US, they had 800 people sitting and doing models and then they threw these models over to the developers and the developers were then supposed to code them, but the developers said this is rubbish. So we did it their way anyway, so there was a complete total disconnect between these two big groups of people.

We tried to change it, but I think the whole organization dissolved and it was recreated without our chance to have an impact. So I mean they were using them wrong. Now, I cannot only blame them. We could have done more to describe it better. So in 2005 we wrote the paper called Use Case 2.0 where we integrated into use cases, something very similar to user stories.

We call them stories, but they were not identical. We had slices. So use case were sliced into a number of slices and you prioritize the slices and every such slice had a number of stories. So we are getting close, but the mistake, I must admit, I think today was a mistake we did like that. We should have kept use the stories outside use cases and we should have integrated it. Whatever way, people like to do user stories. Let them do user stories exactly as we are doing today.

We keep us to simpler use cases and then we have an integration mechanism. We show how to integrate use cases with user stories. And that could be a very simple pattern. So what we are doing now is we are actually doing just that. Our use cases are easily integrated with user stories but user stories all what people have come up with, other people like Mike Cohn has come up with and that is now concrete. So we will have this use case family separate from the user stories and they will be what they are in particularly Mike Cohn's world. So having said all this, maybe I leave it a little.

Shane Hastie: There's a lot there. We'll make sure that we have a link to the ACM article, but if people are looking for some more guidance, where do they go?

Ivar Jacobson: So that is the new thing here in each city. So Alistair and I, we wrote not only this use case foundation, we also wrote a call to action where we said basically use cases fill a hole that none of the other existing practices fill and that hole is an important hole to fill. Then we said, so we are going to do these things. We want to support doing these things.

Number one is to create the use case foundation, which I talked about. Number two was to create a number of initiatives where we integrate use cases with other elements such as user stories, story mapping, and many other practices that are out there and we identify how they can be integrated. I think we are talking about BDD and ATDD as well. So we are working with these people that are founders or have played a significant role in development of these practices.

For instance, BDD and ATDD is Ken Pugh and when it comes to user stories we work with Mike Cohn and also with Gunnar Overgaard who wrote a book Use Cases, patterns and Blueprints. So together this initiative, we develop how to integrate use cases with these other practices and that's going on now. We have identified two such initiatives, user stories and BDD and ATDD, and I expect a couple of others coming quite soon. And that work will be done without Alistair and I trying to play any kind of management role. It's not our style. So we'd see what come out of it, but apart from that we will see people developing their use cases, ideas on top of a foundation. So Alistair is doing that. We are doing that. As I said, we have six practices that we think we will publish in a short while, weeks.

Of course, Alistair is already out training in his new use cases. I don't know if I should call them new, but I believe it's at least refreshing of them and we will do the same thing. Hope to create an interest for them so people can learn about it. And I think we will serve different markets, different part of a market. Alistair has a populistic and still very useful style for doing it. His goal orientation attracts a lot of people. We do it our style, which is probably a little bit more scientific, but let's just guess. Who knows? Anyway, and there are others. I know there are many other people that want to do training and use cases and we will develop our own courses based on use case foundation. So it's all fun.

Shane Hastie: A lot's happening with use cases. What was old is new again.

Ivar Jacobson: New.

Shane Hastie: Yes. So Ivar, again, thank you very much. If people want to continue the conversation, where do they find you?

Ivar Jacobson: LinkedIn. Well I am not shy, so we can get my email address too.

Shane Hastie: All right, I'll make sure we have both of those links in the show notes. Thank you so much.

Ivar Jacobson: Thank you. I appreciate it.

Mentioned:

. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Continue reading here:

The Evolution of Use Cases in Modern Software Engineering - InfoQ.com