This is a transcript of episode 319 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.

“Scope” and “requirements” for software rely on a common understanding of basic concepts like “vehicles” or “names” but humans have no idea how to nail down those ideas.

Show links:

Listen to the episode on SoundCloud or Apple Podcasts.

What is a Vehicle? Where is the Park?

Listen to this section at 00:14

Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.

Jeffrey: Hi, Squirrel. Hey, Squirrel, I have a pretty simple question for you. Maybe a couple questions. Are you willing to answer these for me?

Squirrel: Absolutely! Hit me!

Jeffrey: Alright! First, I had a question about vehicles… do you think a hot air balloon is a vehicle?

Squirrel: Ooh, now that’s an interesting question. Yes, I do.

Jeffrey: Okay. Yeah, no, I do too. If you have ever been to a fun fair, and they might have, like, a hot air balloon that’s tethered to the ground and they’ll sell rides, you know, they’ll let you go up in it, and then they’ll winch you back down and then go back and forth. So, if you’re in that, then you’re in a vehicle, right?

Squirrel: Uh, yeah, I guess so.

Jeffrey: Okay. And so if I were doing that in a park, then you would be in a vehicle in the park, right?

Squirrel: Ah, I see where you’re going, yes.

Jeffrey: Okay. Now, if I was in the hot air balloon, but it wasn’t tethered to the ground, but merely floating over the park. Is it in the park?

Squirrel: Ooh, fascinating. And I think this is the subject of much litigation, right? There are air rights and other kinds of things. So lawyers make lots of money out of questions like this.

Jeffrey: Yeah, absolutely. And it’s one of those things. If you say no, it’s not in the park, well, then… Weird! Is it because it wasn’t tethered to the ground? And yet somehow, is it that ground connection? Anyway, so I think that the point-

Squirrel: What if somebody comes and cuts the rope? Does it suddenly become no longer… is it still a vehicle?

Jeffrey: No longer in the park? Exactly!

Squirrel: There are probably thousands of pages of case law on this question that you could go look up in some dusty law library.

Jeffrey: Yeah. So it seems like it might be a simple question, but as you get into it, it’s not. The reason that I’m asking you these questions, you know the answer to this, it’s because you told me about this really kind of odd online game (link in the show notes) called No Vehicles in the Park. We thought that would be an interesting discussion today. And, you know why did we get into this? What’s the connection between this and Troubleshooting Agile? Why are problems that agile teams encounter related to the question of whether a hot air balloon floating overhead is in a park?

Squirrel: Well, so this goes back to the reason I grabbed this when I saw it and said, ‘Jeffrey, we got to talk about this!’

Squirrel: It is because of a guy named Keith Braithwaite, a very, very clever thinker on all things agile and software and other things. And I remember seeing a talk by him, donkey’s years ago, just ages and ages ago, he mentioned that there were really good psychological reasons there were really well understood notions about why it is that we have so much trouble building software that people want. Because you would think that it would be really simple! You’d go to some people and you’d say, ‘hey, what do you want?’ And then you’d write down the answer, and then you’d build that, and then they’d buy it from you. And if it were that simple-.

Jeffrey: Sounds simple!

Squirrel: -then a lot more people would have successful software companies. Nobody’s software company would ever fail. The problem is, and Keith explained this very nicely, that nobody really understands what human beings mean when they use words. And an example of that which came up in the game that I saw and sent to you, is the concept of a vehicle. And if I say vehicle to you, something comes to your mind. Maybe a car, maybe a hot air balloon, maybe an airplane, something comes to your mind. But then you start to think about your example, right? The hot air balloon is going up and down on a tether, and somebody cuts the rope, and it goes over the park… Suddenly it becomes a much more fuzzy and difficult concept.

Squirrel: And of course, in software we’re dealing with concepts all the time, right? We have object-oriented software in which there are classes called vehicle, and we have definitions of the vehicle. And the vehicle has a speed and the vehicle has a location and stuff like that.

False Things that Software Developers Believe about Names

Listen to this section at 04:23

Squirrel: There’s another fun one, I just thought of this as I was getting excited about it. There’s a wonderful article which we should link to, and it’s something like ‘false things that software developers believe about names,’ and it goes through and lists all these things that you think are pretty obvious about human beings names, but they aren’t actually true like that everyone has a first name and last name. Well, Prince or Madonna. Okay, that’s easy, but, everybody has a unique name. Okay, well, there are people who have nicknames, okay, fine. But, everybody has a legally recognized name. Everybody has a name that is unique. Everybody- and there’s a whole bunch of others that I can’t even think of. Everybody has a name that can be written down, that can be reduced to words. Everybody has a name that is less than 1000 characters, that kind of thing.

Squirrel: It’s another example of this thing, I say name to you, a human being’s name. You think you know what that is, but then you start getting into all the complications of it and all the things that a piece of software forces you to think about, because the computer is going to enforce what seems like a reasonable limit nobody’s name could possibly be more than 200 characters. But then you meet somebody who lives in a culture where names take ten minutes to recite and you think, ‘oh, wait a minute, now, how’s my software going to deal with that?’ Uh, badly, it turns out.

Squirrel: The same thing happens with law and the concept of ‘vehicles in the park.’ We’ll come back to what this game is in just a second. And also what Keith was talking about in this talk, I saw that, the idea that we’re trying to capture is actually not well-defined. So I’d encourage listeners to try this game. It’s very simple game. It’s online. You just answer a whole bunch of questions and then you see not actually a whole bunch. It’s like 30 or something. And each one poses a question that’s like Jeffrey’s.

Squirrel: There’s a good one in there, I’ll spoil it slightly. What if a space station is orbiting above the Earth and it happens to pass directly above the park? Is it a vehicle? Is it in the park? Is it in trouble? Do we care? How would we know? Right? So there are all kinds of interesting edge cases like that. What about a toy car? You know, so it poses all these to you and makes you think, which is one of the things that I really enjoyed about it. So, Jeffrey, did you play the game? Did these questions provoke you?

Jeffrey: Well, you know, I haven’t played the game, but I was very much inspired by the concept, which is that it’s kind of impossible to get a group of people to agree on, on something that seems simple. And it tied really well. You know, you mentioned that Keith Braithwaite had told you about the Big Book of Concepts-

Squirrel: Oh, yeah. I was going to get to that

Jeffrey: -link in the show note. I just read the extract from MIT press about it and the phrase that caught my mind, it talks about, there are things that are phenomenologically simple but actually then difficult to define. And so that is what really made me feel about the link to software and some experiences I’ve had in the past week. Why don’t you tell us about the Big Book of Concepts? Because I think that’s going to be very related to what we get into.

Squirrel: Oh, absolutely. And this is the main thing that Keith’s talk really kind of drilled into my brain because I went and bought the Big Book of Concepts. By the way, do not go buy the Big Book of Concepts, you do not need to read it. I’m going to tell you everything you need to know about it in the next 60 seconds. But I went and bought it, just to save everyone else the trouble, because what Keith said was, ‘there’s this book that’s all about what psychologists have done, and it summarizes all of the the work that they have done over many, many years to try to capture these ideas and model them and predict what people will do when they’re given a definition, like a vehicle, when they’re given a legal definition or a human definition, when they’re given the word, how do they fit things into categories? What do people do with this?’.

Squirrel: And the book is really big, and it contains a lot of dense psychological material, all the research and all the different, you know, it’s almost like a meta study of this idea, this, this difficulty that psychologists have had. But I’ll tell you the punchline, which is none of them can figure anything out. Every study has been completely useless and completely failed in coming up with anything that is better than kind of randomly guessing at what category someone might put something in. The classic one from the book is ‘is a clock a piece of furniture?’ And if you ask this of a large group of people, you’ll get like a 50/50, 60/40 kind of split of people who think different things. Somebody who’s thinking of a grandfather clock thinks, ‘well, yeah, of course it’s furniture.’ Somebody who thinks of an alarm clock or maybe even the clock on your phone doesn’t think of it that way and says, ‘no, it’s not furniture.’

Squirrel: And these people have passionate debates about these topics that are not very productive, which sound an awful lot like software debates about, ‘how should we define this vehicle? What limits should we have on the number of characters in a name? Should names have characters?’ These are the sorts of things that we debate. Nobody understands these things!

What is a User?

Listen to this section at 09:45

Jeffrey: And I can bring up a direct example I experienced in the past week, which was the desire and I think- and I the point I want to make here is- actually I’ll say this, when we build software, we make decisions on these things. And that’s, I think, one of the key points is that, the process of creating the software is to reify some abstract concept into functioning software. So the software embodies a certain set of decisions on what these abstract concepts are. But as we’ve just said, people can’t agree.

Jeffrey: And there’s a couple different implications of that. One is, and I think that was the one you entered with which is the user who you interviewed and said, ‘I want this thing,’ he described in terms of concepts. We went and built something where we created an artifact that that embodied a certain set of concepts. But when those concepts don’t match, it doesn’t give people what they want.

Jeffrey: The situation I was in was, in a sense, worse, where we were trying to bridge two different systems that had similar concepts, that used similar names but meant different things. And these are things like ‘user’ and ‘company’ and this is the gap between what we had in Salesforce. Our CRM, our customer relationship management system, uses these terms in a sort of contractual sense. But then we have our actual operating software and our authentication system. And these systems, you know, we built out our Salesforce implementation, we built out our software, but not at the same time and not the same group of people. And guess what? These terms don’t mean the same thing when you want to try to bridge them. And that’s just, you know, people within the same company trying to agree on a simple terms like, ‘well, you know, what is a user, what is a company?’ And that might seem really simple.

Squirrel: Is a user still a user when they’re out of contract, but they’re still using the product because we’re trying to win them back? That would be an example where Salesforce probably thinks they aren’t a user because they aren’t paying. But boy, the customer service people are right on top of that user. They’re trying to get that user to begin paying again.

Jeffrey: Right, exactly. And what if you have a new user at the same company but they’re not yet under contract? Are they a trial user or not? Because if you have a concept of trial software, that’s different. And the same thing if someone expires, is that a trial or not? What if the same company has multiple contracts? So maybe your question is not actually about companies at all. Maybe it’s about contracts, but even the question of what’s a company when you have these large, multinational conglomerates, when you have Ernst and Young with 85,000 employees in multiple countries that operate very differently, are they the same company or not? Does it matter if we have a global contract or not?

Jeffrey: There’s all these complexities that come into it. That seemed really simple when someone said, ‘hey, you know what? When a company is in this state, we should do this to the users in the software.’ And it turns out there’s a lot more concepts involved than it seems.

Squirrel: Well, I remember going to a very early customer of mine when I was very, very new in building software for large organizations, and I was writing a piece of code that was very low level. It needed to deal with all kinds of these messy choices. And I was making one of those messy choices where something could be empty. And it didn’t make any business sense for this thing to be empty. It could have been the address on a bill or something like that. Like, how would we even bill this person if we don’t have an address?

Squirrel: I needed to know what to do if that happened and it was physically possible in the code. And I remember going to a representative of the customer, and I wanted to have this little interview, and I wanted to say, ‘what should I do operationally? What should we do if the database doesn’t have anything for the address? This customer just doesn’t have an address.’ I mean, these this is a company doing water delivery. So I mean, if you don’t know the address, how could you even have them be a customer, right? So the person I was talking to could not conceive of what I was describing. He just said, ‘how could we have a customer without an address? They couldn’t be getting water from us? It doesn’t make any sense!’

Squirrel: And I remember chasing him down the hall. He walked away from me and I said, ‘but wait! I still need to know. What do I do?’ He said, ‘I don’t care!’ And left. So the point is that when you have this reification going on, when you have these choices that you’re making about a concept that your users understand and possibly quite differently from you, the only thing you can do is probe sense and respond. The only thing you can do is operate in the-

Definitions by Trial-and-Error or Through Conversation

Listen to this section at 14:38

Squirrel: If we refer to cynefin that we’ve talked about a lot, the complex domain, you have to try something and you have to put it in front of them, and you should expect that they will say, ‘hey, wait, this clock is not furniture.’ ‘Hey, wait a minute. This vehicle is not in the park.’ That’s part of the process. And something both you, and they should expect, and probably not so useful to chase them down the aisle. But you do need to get resolution on these questions. The only way I know to do it is to experiment. Very, very smart people spent a very long time trying to figure this out in an abstract way, and have failed completely, so don’t feel bad if you do.

Jeffrey: There’s a couple other things where this comes in, because you’re talking about it just in the terms of the customer and the company that’s going to build the software, as though the people in the software company all share the same concept. But of course they don’t. And this is where some of the problem comes in the discussions about are the requirements done or not? You know, did scope change right? This is the classic question for the debate between product and development is why are we late? And it’s the developers saying, ‘well, product kept changing the scope’ and the product people say-

Squirrel: ‘Yeah, they wanted us to deal with trial users!’ ‘Yeah-

Jeffrey: Exactly!

Squirrel: I mean, we never thought- we said users. What do you mean? Where did these trial users!’ That’s extra scope. ‘Well, I guess it’ll take a few more months.’

Jeffrey: ‘No, no, of course we meant all users. Of course, when we said users, we meant all users. So-‘

Squirrel: Yeah, including the trial users, you knew that! Back and forth we go.

Jeffrey: Isn’t that obvious? Exactly. So this is actually why there are techniques around how you, in a software project, can and why you should try to create what’s called a ubiquitous language. And this is often the point where I would introduce people to the concept of domain driven design and the concept of a bounded context. And the these are kind of jargon words, but what they mean is, ‘when we go and build software, we need to agree on what the words mean so that we can when we’re having a discussion, you and I mean the same thing by it. And you know what? We can’t just go look up at a dictionary. We have to define it together. And then we need to write it down, we can refer back to it later. And then we can use these words in our documentation, in our software and know that at least we all agree with each other.’

Jeffrey: And that’s kind of the point of creating a ubiquitous language. We’re going to use the same terms to mean the same thing everywhere. But one of the parts I like about it is this idea of a bounded context, which is to say these words that we’re defining, they’re not going to have universal meaning. They’re only going to have a meaning that’s shared within the bounded domain that we’re defining together. And so later in the future, we should know these words won’t mean the same thing across systems. If we want to go and suddenly have our systems talk to each other using similar terms, we’re going to have to define a new bounded context and come up potentially with a new ubiquitous language.

Jeffrey: And so that whole concept that’s built into this is very much built on the principle that language is not universal. The concepts that we think of phenomenologically, that we can use and have, what we feel is a very definite grasp of, are in fact squidgy things that are hard to pin down and impossible to pin down definitively among a group without putting the work in to come up with like, ‘yes, this is going to be our shared meaning.’

Jeffrey: And that is an essential part, in my experience, of building software systems, if you want them to be successful, is to go through this process, and you can either do it deliberately, or you’re going to do it accidentally and expensively, through a lot of rework and a lot of back and forth on requirements. And in my experience, that part takes a lot longer. So that’s a choice! You can do this unconsciously, evolve it over time together, or you can deliberately set out to define these things. And that’s something that I have found to be much more effective.

Squirrel: And the important thing that Keith Braithwaite and the Big Book of Concepts teaches us, is that that ubiquitous language is not going to be stable and consistent and always the same. Things will change in the universe, things will change in culture, things will change in your understanding of what users think. And they’ll come along and say something like, ‘hey man, did you realize that we sometimes have trial users who never convert, and they actually never wind up paying us? Yeah, that’s got to be a different kind of user.’

Squirrel: And they realize that halfway through the process. So they may have agreed with you something, but that’s going to evolve. Or they might agree ‘hey, we’re going to make sure we record a gender for each person, male or female, right?’ Well guess what? Now we have a whole bunch of new things because the culture changed, and we have different ways of defining people. And people reject those criteria. So if you have a database from 40 years ago, it might have been ubiquitous then, but the language is no longer ubiquitous. And that’s when you’re going to have to evolve it. So the most important thing listeners should take away from this, I think, is: don’t feel bad when you have these kinds of problems. Everybody does, for a good reason, and plan to mitigate it. Plan to define the language as best you can and then evolve it as you go. What do you think, Jeffrey?

Jeffrey: Absolutely.

Squirrel: Excellent. Okay. Well, if listeners have been confused by our language and want to ask us about it, or if you have a different way of approaching requirements. My least favorite word, I hate that word and I outlaw it from all my clients. But if you have a different way of defining them, you avoid scope, challenges and debates about changes in scope in a different way. We’d like to hear about people who are confused, disagree with us, or have interesting stories. That leads to the most interesting conversations for us and Best Future podcast episodes. And if you’d like to, you can come back and listen to us again that’ll be next Wednesday, when we’ll have another edition of Troubleshooting Agile. Thanks, Jeffrey.

Jeffrey: Thanks, Squirrel.