This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub
So, welcome everybody to another episode of Software-Architektur im Stream, this time with Alistair Cockburn, and let me spend a few words about why we are doing this episode.
So 14 days ago, we had Software Architecture Gathering in Berlin, I did a presentation, and Alistair joined, and we had, he also had some interesting discussions with some participants afterwards and also with me, and we thought that we would open up that discussion and have it here in the live stream.
So thanks again for Software Architecture Gathering, and Alistair, do you want to say a few words about yourself?
Sure.
Hello to everybody in wherever you are, Germany, Europe, or around the world.
I’m Alistair Cockburn, and if you look at the name, the CK is silent, I have to say this all the time.
So it’s a Scottish name and it’s pronounced Cockburn, and that’s the thing that I have to do in all of my books and things.
I was a hardware designer first, so I know a fair amount of old school hardware design, and then I was a researcher, programmer, and then I became a methodologist and started studying processes and methodologies for teams, mostly for Smalltalk and C++ projects in the 90s.
So I was a Smalltalk instructor, and I had a week-long course on object-oriented design.
That was all in the mid-90s, and that was like the hot time of trying to figure out how to do object-oriented design, and that got me naturally into the question of modularization, how do you assign code to objects and so on.
That kind of left that, hexagonal architecture came back into my life, so I’m known for hexagonal architecture, and then I heard Eberhard give this great talk on modularization, bounded context, and event storming, and since I’m not so up on bounded context and event storming I went to that, but I know about modularization, and I loved the talk, and I wanted to have more conversation about those elements, and so did Eberhard, so here we are.
We don’t know, we have a couple of topics, but we don’t know what we’re going to say.
Yeah, and obviously you’re the person who actually invented hexagonal architecture, if I’m not mistaken.
Yeah, that’s one of the few things that I invented from whole cloth, because I’m not a system programmer, I’m an application programmer, and they kept not giving me the ability to test stuff when things went down, and so I very slowly, over a period of years, worked out what they should have done, and then I just said, I know I’m entitled to this, give me this, and then slowly worked that out, and that’s hexagonal architecture, or ports and adapters, to give it the correct name, but the marketing term is still hexagonal.
Yeah, and also you’re, what is it, like at least, you’re the author, or one of the authors of the Agile Manifesto.
17 of us, 17 of us, I’m one of 17, we have to be always very clear, 17, yeah, we did that.
Okay, so, as you said, there was that presentation that I gave, and one of the things that I talked about, and I can’t stop talking about it, is the Parnas paper about modularization, which talks basically about how modularization allows you to control the information flow across people in the software development environment, so basically to hide implementation details so that they can be changed.
Other people wouldn’t know the implementation details, and you would just rely on the interface.
I think that’s basically what it boils down to in modern times, and obviously it’s more it’s about hiding any kind of information, and you basically said that the other, that other Parnas paper that talks about, I have it here in front of me, on the criteria to be used in decomposing systems into modules, that that’s the one that is actually more important to you, and I found that interesting, and I want to say maybe two sentences about why I think the information flow one and the information hiding one is interesting to me.
So I keep asking people why you wouldn’t expose instance variables from a class, and they all agree that you must not do that, but it’s hard for them to actually give the details why you wouldn’t do it, and in my opinion, the reason why you wouldn’t do it is because if you have, for example, the account balance as an instance variable, and you have direct access to that account balance, you can’t change how the account balance is modeled, so if you want to calculate it on the fly based on the transactions, well, you can’t do it because it’s exposed.
And I see a lot of people on the more cost-grained level who actually give access to databases, and that’s basically the same problem.
So then you have the data model in the database, nobody can change it anymore, and it’s really hard to get rid of it.
And I find it interesting that, well, nobody knows that, or at least it’s very hard for them to give that train of thought or whatever you want to call it, and therefore that’s the reason why I keep referring to that paper.
Anything you want to add?
Anything?
Yeah, I do.
So this was the area I studied in the 90s, like really, really, really hard.
And for me, I’m going to come back because what I think is fascinating, like that was 30 years ago, and I’m guessing you were programming back then, right, 30 years ago.
So there were those of us who kind of went to the same school, like in the early 90s was a really rich time, a very good discussion around why are we doing, what are we doing, and we really locked down a bunch of answers.
Like in the early 70s, Parnas’s time, they did, so did we.
Now it’s 30 years later, and people coming in, of course, don’t live through that conversations the way that we did.
And the phrase that I like to use always, I’ll come back to, is the trajectory of change, trajectory of change.
When you have to make a change, you know, and you start here, how many modules, to use it loose word, right, how many modules do you have to go across before you’re done, right?
And if you’re one, you’re home, if it’s two, it’s okay, and it gets worse.
So we’re always talking about that, and this goes back to Constantine’s paper about, you know, cohesion, coupling, and so on.
But when you come to instance variables, very particularly, it’s a tiny little subnote that I got into at one point in one of my first patterns papers, and I called it, I think I called it change behind interface or something like that.
And there are some languages, the point I got to right there, there are some languages in which, in the call, you can’t tell if you’re accessing the instance variable directly or it’s a function, smalltalk being one of them.
So you say, you know, instance variable, colon, right, or something, and you can’t tell.
Now, that already gives you this protection that you’re after, and the kind of thing that I was big on in the 90s was the client, it’s none of their business if it’s cached or calculated, and the fact that you have to make a syntactic change in the source code to distinguish that to me is a design, it’s hard to say design flaw in the language, but it’s not nice, it’s an oops, right?
So in the languages where you can’t tell, you automatically get this protection you just mentioned that the person says, I want that, and then it’s a local design decision, and we’ll get into that with the bounded context, so I use that, it’s a local design decision if it’s cached or computed, right?
So now when I have to go to languages where there is a syntactic difference, now, because we used to fight over, we’re going to have accessor methods or not, and the code bloat, and all of that, that is a discussion I would love never to have, but then I get it, the reason you do the accessor methods is exactly to create it so that the caller doesn’t know, can’t know if it’s cached or computed.
So yeah, that’s what I have to say, I’m in 100% agreement, but that’s a funny little footnote in history for some people.
Yeah, and I think that’s one of the reasons why you can, I mean, I think Smalltalk did it sort of the right way, and then we had Java, and they didn’t do it the right way, so that was clearly a step back.
So there is that other paper that we just discussed?
Let me know when, because I love that paper so badly.
It’s the foundation for, you know, like half or two-thirds, we’ve got the Peter Naur paper from 1986 on programming, we’ve got this paper from 1972, these are so core, and I found the key phrase.
So it’s, again, always been on my mind that people say information hiding, and you do also, and they draw something that I don’t think is in the paper into it, so they draw meaning into it that’s implied to them, but not explicit.
That was in 1971, he did the information hiding paper, which I have in front of me, but not in front of me.
Then in 72, he came up with this other one on the criteria for decomposing modules or something, and in the very conclusion he has the sentence I just would love to put for everybody, we propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change, period.
Now watch, this next sentence is the one.
Each module is then designed to hide such a decision from the others.
It’s not about hiding the data, it’s hiding the decision, and now we take the accessor methods, right, as a cache to compute, that’s a design decision, we’ve hidden that decision.
So for me, the subtle way of looking at the information hiding, where you’re hiding is not the data, so information hiding is the wrong phrase, you’re hiding the decision why so that you can reduce that trajectory of change.
So that’s how the blur between information hiding and this other one comes in.
So I found that sentence, if I could plaster that on the wall in all the programming rooms, I would love to.
Yes, so it’s more like decision hiding, that’s basically what you’re saying.
Decision hiding, 100%, yeah, and that’s the basis for me for all the stuff that I learned from, you know, Ward Cunningham, Kent Beck, Rebecca Wurstruck, all those people.
Yeah, so I have to admit, the problem that I have with these kinds of things is that it’s a fundamental problem, and that’s, he said, it’s a decision that is likely to change, and how can you know that if, because you can’t predict the future, so therefore I’m not sure about that, and it’s also a very generic statement, right?
So and then I, yeah, but that’s probably me, I get quite scared of people trying to build systems that are so generic that, you know, everything they decide is somehow something generic and then you have overly complex systems, and that’s basically the problem that I have with these kinds of rules.
I mean, I see where they’re coming from, and nowadays, I believe we probably have some ideas about what is likely to change, but generally speaking, I’ve seen that fail as an approach quite often.
Yeah, so this is good, and thank you, because, you know, we’re in an engineering profession, and in an engineering profession, there’s always a push and a pull, there’s always two factors, and there are simplistic rules that I don’t care for, like the law of Demeter, for example, which says you can’t cascade, you know, the methods, and at first glance, it sounds right, but when you see all the code, it gets really kind of like very, very, you know, long, and you go, well, as a general starter guide, like, I’m with you, but watch out for the exceptions, right?
So same here.
What you pick up on there in the late 90s, when Kent Beck, sorry, there’s some light coming in the window here, I’m just going to see if that catches it, yeah, in the late 90s, when Kent Beck was coming up with the extreme programming stuff, I was also doing the same thing, which was simplifying software design, which is, in fact, going to be my next book, but we were like, everybody’s being too complicated, and we had the operating system, Paligent, that came out in whatever, 92, 93, and they put, there’s like, to me, like, if I look at an analogy, like hinges in a wooden structure, and every time you make a new class or a new function, you get a hinge point, right?
And so they were going to be so general, and they put hinge points everywhere, and the net result is you have a structure that’s not got any stability if it’s a mechanical so you have hinges everywhere, and if it’s in software, it’s so complex, you can’t find anything anymore because it’s got too many hinge points, right?
So there’s this push-pull, and so Kent Beck came up with YAGNI, right, you ain’t going to need it, to force people to simplify, and I was in Norway at the time teaching a graduate course in design, and in my final exam, I said, you get one class to design this problem, what are you going to choose?
Design this problem.
You can now have as many classes as you want, design this problem, and I wanted them to see that progression and complexity.
So yeah, it’s a terrible thing, everybody says, yeah, but maybe, yeah, but maybe, and so we have to socially fight against the yeah, but maybe, and still look at, and when you go, what are some typical changes, come on, you know, we change these kinds of things pretty often, et cetera.
And at the same time, not becoming over-generalized, yeah, I think that’s good, and just because you mentioned it, Trident, I think, was, is a failed project, right?
I mean, it never did look good.
You know, I knew enough at the time, it came out, and everybody was excited, and I just looked at the number of hinge points, and I went.
I’m too stupid to use this, but I don’t see how this can work.
And then, you know, three years later, it failed.
Yeah, and it was a large, very important project for, I think, IBM, Apple, and so on.
Yeah, IBM was in it, and, you know, they had all these super-duper programmers.
But if you look at it from our perspective, it was overly complicated.
And what does that mean?
So, oh, we’ve got this information hiding, we’ve got to encapsulate design decisions, we’ll make everything its own class, and that’s super modular, right?
And then you just explode the brains of the reviewers.
So, we’re dealing with the complexity of the human brain as well as, you know, these are the push-pulls that we’re trying to find the simplest thing, right, so they can be understood.
But if we select it correctly, then the changes are natural.
Yeah, and it’s just, I think, very important to point out that the sort of smartest people that we had in the industry, and I think quite a few of them worked on intelligent, failed to build this over-general system.
And there was this other project, IBM built the San Francisco framework as a general framework for business applications.
And that was supposed to be like the one very, one of the two very important projects that IBM did by that time.
The other one was the PowerPC processor, and it also failed miserably.
So, you know, you can fail big time.
Shall we cycle back?
Sorry.
Yeah, come back.
What’s next on your list?
Yeah, I just, so, because we just discussed the paper, there is another, so that’s one very important part of that paper.
The other important part of that paper is it talks about a system to, it’s called the quick index production system, and it’s supposed to calculate all circular shifts of all lines in alphabetical order.
So, it’s some, I would say, rather technical problem that Parnas talks about.
It’s not some business functionality.
And the point that he’s making is, he gives two different modulizations.
So, one modulization, in his opinion, is by the flow.
So, it’s input, circular shift, alphabetizing, output, and master control to sort of control everything.
And then there’s the other one where he adds the line storage that hides the decision to store the data in a specific way.
And then he goes on to say, so I read it up after you mentioned the paper.
Then he goes on to say, well, if we want to store the lines in core, I believe that’s sort of what RAM is these days.
Or if we want to pack the characters, four in a word, so that we have, you know, four bits representing a character, I think that’s what he’s trying to do.
Then in the first modulization where we don’t have line storage, it’s cross-cutting.
It changes basically everything.
And the conclusion that he draws is, if you build a system by the flow, so have, you know, one module for each step, that’s a bad idea.
Sort of that is what he proposes.
And I have to admit that, based on this example, I sort of dismissed that paper because, first of all, you wouldn’t write such a system these days because it’s just a few library codes that you would put together.
So, we have a different level of things that we are building these days.
This is not what we would code.
It’s just something where we would use a few stuff from the standard library.
And then the other thing is, if I look at typical systems these days, storing things in a database, for example, that would be the analogous design decision that we are talking about, in my opinion.
That is something that people separate.
And, you know, they do it with layers.
They do it with a hexagonal architecture or ports and adapters or clean architecture.
And it’s very, I would argue, it’s very clear that you must not have that decision all over the place.
Boy, oh boy, oh boy.
Does the industry ever disagree with you on that?
Like, I agree with your philosophy.
You see people, not even me, trying to sell the hexagonal architecture idea.
We know it’s an SQL database.
I’m just putting it in here.
Like, don’t make me put one more nananana layer of complexity nananana.
Now listen to us, doing the opposite of the Yagby.
But you might change it, right?
Ah, screw that.
When it comes, we’ll just change it, right?
So the predominant, the prevalent design technique in the world that I hear from everybody is, no, you don’t put any, you go, it’s SQL, what the hell?
And you tangle in the SQL linkage right in the code, business code, everything, all the way through.
So there’s no encapsulation.
And then, and then one day they decide to go, you know, non-SQL or whatever, some other really different technology, and then they’re stuck, right?
And so, and so I think it’s, let’s say, optimistic thinking to think that people do do that, that my experience is they don’t, and it’s still a hard sell, exactly even just the database.
So, you know, I like that because basically what you’re saying is that your perception of the world and your experience is different from mine.
And I mean, I’m totally fine with that because we live, well, we see different stuff, right?
And then we draw different conclusions.
So I, that’s, that’s perfectly fine.
And that is also one of the fundamental things that I try to do in my consulting work, except that people have different views on the world and different, different problems in their subjective field.
And then if you, if you don’t try to understand that, or try to say, okay, I see where you’re coming from and I see why you come to that conclusion, I come to a different conclusion.
And, you know, there is a reason for that.
That’s totally fine.
And, you know, I’m not sure whether it’s optimistic, it’s just a different perception of the world and maybe, you know, where you, where you go, right?
So maybe you go to places where people know who you are, and they’re already at a certain level of thinking.
And I’ve just got this paper and people write to me randomly off the web and go, why would I do that?
I’ve got, right, so I get these random notes showing up.
Yeah, maybe, maybe that’s the problem.
So that people keep going.
So I did want to pick up, because while you were talking, I wanted to think about, you know, when you said, oh, this, this thing, it’s just, you know, code in the standard library, this pattern of thought has been encoded in the standard library, when you go get yourself an ordered selection, you don’t know if it’s an array or a link, you don’t know, you don’t care.
So it’s bundled in, when you go to do some output, you say, output this thing, right?
You have a DTO or whatever, right?
So the good news is this fight from the 90s got itself encapsulated into a lot of the, what you call standard library.
So people don’t think about it anymore.
Like, I remember in the 90s, having to write a transaction class, mid 90s.
And I didn’t have to write a collection class, thank goodness anymore.
But I said, I look forward today, I never have to write a transaction class again.
You know, we should just be done with that stuff.
So there are certain ones that are now, they’ve got all the proper encapsulation, the decision hiding, and so on.
So we have made progress in that sense.
Yeah.
Yeah, great, isn’t it?
So there is another point, I mean, concerning the perception.
So I would basically go on and argue that technical people, I mean, I studied computer science, why did I do that?
Because I’m interested in technology.
So I would consider myself a technical person.
So I believe, but maybe your view, again, is different, that people go to great length to have these kinds of technical discussions.
Like, you know, how can we separate our system?
And how can we have technical decisions and whatever done in a clear manner, and so on and so on.
Yeah.
And what I, and again, that’s about, you know, my perception and what I’m trying to do.
I think the most important part is actually about structuring domain logic.
And if I look at bounded context, for example, and also about in particular, if I look at event storming, in event storming, you know, you would have these events that happen in the, out in the wild, like, you know, you accept an order, something is added, was added to a shopping cart, and these kinds of things, and you will bring them in a timely order.
You would have these pivotal events where things really change, like you would accept an order, and then you do have an order while before there was a shopping cart, so the world has changed.
And there are parallel activities like invoicing and shipping.
This basically says, if you take, attack the problem from the point of view of what happens in the timeline, this might be a way to come to some kind of modularization.
And I would argue that’s not, that’s built in the method, because if you have a pivotal event where the world changes, well, it means that probably this change is enough to justify a new model.
And if things happen in parallel, and there’s little communication between them, well, it’s maybe, it might be a model or different modules.
So, to me, it seems like a good way of doing, well, at least a rough sketch of the domain architecture.
You still have to think a lot.
Yeah, I got it.
And let me, go ahead, you finish up, because I’ve stacked up, but I want you to finish all of your sentence first.
Yeah, sorry.
So, the remark that I wanted to do, and that is the reason why I dismissed this Parnas paper, is basically, I think this is a great way to, you know, by the time, to look at the time, how things progress during time, identify these pivotal events, identify parallel activities, use that as an approach to build modules.
And basically Parnas says, no, you shouldn’t do that.
You shouldn’t build your modules according to the workflow.
And that is why I thought, well, you know, these days, things are very different.
So, good.
So, here’s what I, where I went in my head.
So, I don’t disagree.
So, I don’t disagree with what you said, first of all, so I’m not going to disagree.
But I want to kind of frame it for the listeners in a slightly different way, because you did a little shift on the words that other people wouldn’t catch.
And I think that that shift is significant.
And I’m trying to think, because I’ve got like two thoughts in my head.
So, that’s always hard, which thought comes out first.
The lines of code he’s dealing with there correspond to different layers of a layered architecture.
He’s really dealing with IO, right, versus business logic.
That’s really, his big separation really is business logic versus versus IO.
Your conversation was entirely in business logic, not including the technology.
So, you had, in a sense, already separated out.
Now, when you say, in a sequence or not in a sequence, this is a subtlety that, you know, maybe our listeners wouldn’t pick up on.
But it’s the thing that caught me was, you first said, without saying it, let’s take all the technology topics and push them off the table.
We’ll use hexagonal architecture or similar.
And we’ll do that.
So, you’ve already applied Parnas’s decomposition rule for getting the variation of technology out of the discussion.
Now, let’s say, on a pure business perspective with no technology in, let’s see if sequencing by time makes sense.
And we’ve got these events and the state changes.
And that’s very cool.
Like, no disagreement.
It’s just, I didn’t want to link the two.
Outputting to a printer is not the same as a transition in a shopping cart, right?
So, there’s a level shift.
Now, there’s a thing that I want to bring up.
I have these dangling mysteries that I’ll keep forever in my life when somebody says something intriguing and I can’t anchor it.
So, in my very first interview, like in 1991 or 1992, there was a guy whose name is Dave Thomas, not the pragmatic programmer, Dave Thomas.
He was the owner of Object Technology International.
And now he’s wherever he is in the world.
And that got bought by IBM and his team built Eclipse.
So, he was a super sharp guy.
My very first interview, how do you do object-oriented programmers?
And he said a thing that I had been waiting to see in action my entire life, still not seeing it.
And he said, in object-oriented programming, you build up a vocabulary.
And so, let’s say you’re doing hotel reservations and stuff like that, travel planning system.
Well, first, you’re going to build up a vocabulary of tickets and hotels and bills and invoices and things.
And then given that vocabulary, because you got nouns and verbs, right?
You can build up a vocabulary of reservations and cancellations.
And then from that, you can build up a trip itinerary.
So, you’ve got these layers of language that come.
And lower level means a more basic vocabulary that you’ll utilize.
And that was in 1991 or 92.
And I’ll tell you, I have looked for like 30 years.
I want to see that in play.
And I don’t see it explicitly, but I always remember it’s such a very clear description of what’s happening in object-oriented programming.
And so now, if we take your thing with the bounded context and the event storming and the cuts, and we say, okay, so like anything that’s I.O., first of all, it’s pushed off the table.
And now we’ll build a vocabulary of shipping addresses and the act of shipping and invoicing.
And then we have an order item.
And then we can start to build up these things.
And I wanted to mention that because I love what you do with the bounded context and the event storming and the categorization.
Again, all of this is just a slightly different way of framing what we’re doing and saying, look, at the bottom level, I want some things that talk about the things that I want to deal with.
And then I’ll deal with ways of assembling them.
And those things you’ve talked about from the event stormings are the ways of assembling them.
Yeah, and I totally agree.
I mean, that’s basically this prioritization where I think that the technical stuff, well, that’s well understood, I believe.
And then we have the domain logic stuff and that Panos talks about more technical stuff.
I think that’s because of the time when he wrote the whole thing.
There is one thing that I learned from your feedback on the presentation also concerning that paper.
And that is that you said, well, the paper actually talks about how we come up with modules.
And I think you even said that modularization or modularizing is a verb.
So it’s something where we do something to build the stuff.
And obviously, well, not obviously, but that’s probably the thing that we have to care about the most.
And that is something that information hiding basically just says, okay, if you have modules, you have a way to limit the flow of information, but it leaves open the question, how do you come to those modules?
And Parnas basically answered that in that other paper.
And we can discuss whether that’s a good or a bad way to do that, as we just did.
But it is probably, and that’s what I learned from your comment, it’s probably the more important thing to come up with a way to build those modules and do the modularizing.
Now, yeah.
And so, again, two thoughts, CRC cards and Barry O’Reilly’s residues stuff, right?
So, in the CRC card stuff that I wrote back then, I’m rehydrating and rebuilding it into my next book, we would do scenario variations.
And I remember also Jim Koplein talking about it.
He was at AT&T working in C++.
And you throw a bunch of possible changes.
And the idea, the beautiful thing with the CRC cards is you pick up this object here and you say, well, this is the article that’s going to be shipped, right?
And then, okay, well, this is the person that’s going to…
And then you move them around.
And then you literally, while you’re doing this and you’re practicing moving them and having a conversation, and then someone says, but what if they split their order?
Or, but what if they use two credit cards?
But what if…
And then you look at the movement of the cards and the changes.
And so, what you’re doing is a change analysis, a variation analysis of a certain very simple variety, where you’re trying to find out if those things change, then this holds pretty well, right?
And now we’re in this, the thing you mentioned, we’re in speculation, like, will it or won’t it?
How adventuresome do you become, right?
And then Barry O’Reilly shows up with this thing about residues and you do like crazy, crazy changes.
And then you do this with some other tools and so on, and you find out it’s stable, right?
So, the variation analysis, if you don’t do it, I think you come up with some optimal design, one that’ll have trouble.
And then the question is just how adventuresome do you become, extravagant do you become in your scenarios that you throw at it?
Yeah.
And I have to agree.
So, we did an episode with Barry not too long ago, and I’m going to link to it in the show notes.
And it might be a missing link in software architecture, because he basically says, if you have all these changes, even improbable changes, you will end up with some architecture decisions that are the solution to quite a few of these challenges.
And that’s a good thing to do.
And that might be a good solution to this.
Should we rather build two generic systems or two inflexible systems?
And it seems like this might be something that is really, really interesting and helpful.
So, that’s a good point.
And the other thing, so you shared that draft of your new book with me, and you talked about CSE cards.
And I found that quite interesting.
So, do you want to say a few words about CSE cards, or shall I try to do it?
Oh, you go first, and then I can build on it.
Yeah.
Okay.
So, my understanding is CSE cards, it’s an acronym.
So, the first is class, then we have responsibility and collaboration.
And I know it as sort of a game to come up with a good object-oriented design where you would have a card for each class that you envision, and that one would have responsibilities.
So, it itself is responsible for specific things in the system.
And then it has collaboration with other cards.
And then you can go through some, I don’t know, use case or whatever.
And you would have those cards, you can even distribute them across your team.
And then you would try to say, okay, so I’m going to do, I don’t know what.
So, I’m responsible for accepting that order.
So, I need to write an invoice.
So, I talk to the invoicing service, and then you hand it over to whoever has the card for the invoicing service.
That’s my understanding.
Yeah.
Now, it’s fun.
I’m linked enough back into the history of our industry.
I have some fun tidbits and rumors.
So, unconfirmed rumor, but I happen to think it could well be true, that the reason it’s called CRC cards is apparently, so rumor, unconfirmed rumor reaches me, but it’s kind of fun.
We’re talking 1987, 1988, and we have Ward Cunningham and Kent Beck.
Now, Kent Beck is a specialist at naming things.
He’s really, really good.
And he wanted to, so the word reaches me, he wanted to call it Name Responsibility Helper, NRH cards.
So, you have the name of the class, it’s responsibility, and it’s helpers.
And here’s the unconfirmed rumor part, is that Ward Cunningham’s son was busy being born about that time.
And his name was something like Christopher Robin Cunningham, so CRC.
And so, I have not double checked with Ward.
I’m sweating now, Ward, please forgive me.
But it could be.
Anyway, yeah.
So, the idea was you would write here, on here at the top, you’d write the name of the class.
And the thing that the tools never supported, and if the tools don’t enforce it, nobody really does it.
And Rebecca Wiersbrock has written a couple of books about it.
You go, what is it good for?
What’s its intention?
What’s its purpose in life?
But you get one sentence, and it’s a short sentence.
You get maybe two sub clauses, but that’s it.
And you write that out in English.
And then, after that, you could say, well, it’s gonna need these other objects to get its job done.
And this is very sad, and this is really the basis for all of my teaching and the new book, is these three things, if we take the method signature down here, you could also include the method signatures, they need to be in alignment.
So, if you get up a good name, nobody knows what you mean.
You say invoice.
Of course, we have an invoice.
I don’t know how much active responsibility does it have.
Is it just a dead data object, or does it babysit the object all the way to delivery?
You don’t know from the name.
The responsibility tells you.
It’s responsible for this, but not this.
And then, the signatures is the implementation.
Now, you’re designing.
Designs drift.
As you’re talking and coding, these things are each gonna drift over time.
And you don’t know which one’s wrong, and you don’t know which one’s right.
And my point isn’t that there’s one that’s right.
You’re looking for an alignment between the three.
When they get out of alignment, you have to rethink.
This is the Eric Evans book.
You have to rethink, what are we on about?
Did its name actually change?
Or did its responsibility change, and I should change the response because I now agree with it?
Or did this get out of bounds, and we put too much stuff in it, and now it’s out of alignment?
So, that alignment allows you to think about, as things drift, what happened.
And it’s interesting because I think that’s a sentence from your book.
I actually copied it over to the notes for this show.
So, it said, if I compared the name of the object, the responsibility statement, and the data and method signatures as one thing, then I could detect if something was out of alignment.
And I thought, at least this idea of a responsibility statement is a great idea.
And the other thing that I’ve… I mean, CSC Cards, as you mentioned, 90s, probably.
I think the paper came out in like the Uppsala 1988 conference.
So, they wrote it in 1987.
And so, it’s like really sort of old stuff.
And what I find interesting is that nowadays, we have all that fuss about collaborative modeling.
And that’s a tool that does exactly that.
So, if you use the CSC Cards in your team, and you talk to other people, and you sort of, well, you play your system using these cards, that’s collaborative modeling with a different technique.
And I wouldn’t see, and I think that’s also the point that you’re trying to do, to make in your upcoming book.
Yeah, maybe, I don’t know.
You can use that, not just on classes, but also on more course-grade stuff.
Exactly, exactly.
And the macro system structure, if you, again, just do the responsibility statement for each of them, boy, is that ever a clean way to document your system.
Yeah.
So, it’s definitely something that people can try out to come up with a great design.
And also, that’s the other aspect.
Much like with collaborative modeling, you have a shared understanding if you do that, because you play that with distributed roles, and therefore, everyone will get an understanding about what’s going on.
So, I want to pick up, if I can, one thing, the reason that I’m coming up with this new book, because the book is just the stuff from the 90s, right, CRC Cards, was I found that there’s a twist that I do that’s unique to me, that’s not done by Rebecca, not done by Ward or Kent.
You know, I fell into teaching their stuff in 1990, and I taught it from 1990 to 1995.
So, I came in through CRC Cards and Responsibilities.
But somewhere along the line, because I’m a big fan of simplifying stuff, and the reason the book is subtitled The Genius of Bureaucracies is because the hallmark of a bureaucracy is people say, it’s not my job.
That’s really the hallmark, you know, the reason we don’t like bureaucracies as humans is because you go somewhere and they go, not my job.
Now, if we take a look at encapsulation of design decisions, not my job is perfect.
And I had this fabulous experience teaching a couple of FBI agents who were total newbies, and that’s my intro.
And I give some problem, and I come over to their table, and they had a pretty subtle little design, and I went, oh, that’s kind of nice, like, what’s that?
Why do you have this?
And they go, this object has no need to know.
That’s FBI speak, right?
I said, man, you guys are perfect.
I could teach FBI agents object oriented design all day long.
So, now if we look at our design, let’s say you’re doing this thing with the responsibilities, what we’re looking at is when you speak it, like as humans, we know about bureaucracies, we know not my job, we know about this, it’s my job or not my job.
When we role play those cards and someone’s holding it, and they ask it to do something that isn’t right, man, that it’s not my job comes out so fast.
And that now becomes a really very powerful, simple, human, intuitive way to judge a design is just like, it’s not my job, or that object’s got no need to know, right?
And there’s your information hiding thing, right?
So, it just these two phrases, you get some really, it’s very simple, coarse grained, it may not be A++ design, but very simple, pretty decent separations that get you like a good distance, which is the kind of stuff that I look for in life.
Yeah.
And just to add sort of my understanding, I mean, it’s not my job from a bureaucracy.
I think that’s pretty clear to everyone.
This need to know is about information hiding and to not give people information that they don’t need to get their job done.
So, they would be told to achieve some goal to do something, whatever it is to research some information, but nobody would tell them why, so that it’s more secure, right?
Well, your example with the accessor methods and the instance variables is perfect.
Like, the client has no need to know whether that’s cached or computed.
Yeah, I’m just trying to say that in the intelligence world, that’s the reason why you do this need to know thing.
Secret information leaking.
I had a small anecdote back in the Bush presidential era and the war in Iraq.
He made a comment, apparently, I missed it, that saying we needed the armed forces to be more agile.
So, all the people were scurrying around trying to figure out what agile was.
I got a call from his feeder network and said, we want the NSA and the CIA, we want our intelligence forces to be more agile.
And I said, well, I can tell you how to do that, but you can’t do that.
And I can tell you why you can’t do that.
And the first thing is, to play agile properly, you have to have serendipitous discovery of information from other parts.
He goes, we can’t do that.
I go, of course not.
You exactly can’t do that because you’re full of, right, no need to know.
Yeah.
So, here is a funny thing.
So, I did an episode with a German officer, because there is, I think in English it’s called mission tactics, in German it’s Auftragstaktik, where you would be assigned to reach some specific goal, but it’s left to you to how you achieve that goal.
And that’s clear delegation, self-organization.
And I actually found, the reason why I did that episode is because I found that those agile principles, I would argue those are agile principles, are actually something that at least the German military uses ever since Prussia in the 18th century.
And I found that interesting because you would assume that, you know, in the military, you have to obey orders and you must not ask any questions.
And it seems to be different.
I mean, I haven’t been in the German military after a bit, so I don’t have a first-hand experience, but I found that interesting.
Yep.
No, I read the same thing in English in the US.
It’s since the 90s, you know, whatever the Kuwait, you know, that thing was in the 90s, became all in the literature.
And I don’t know anything about the military to what extent they do or they don’t, but I read the same words So, yeah.
And wasn’t that the discussion that we had, that like, it’s not about agility, it’s not about, it’s a business principle and it’s about effectiveness and efficiency, it’s not about sort of the welfare of the team.
Right.
I don’t know.
So, is there anything left stacked up on your list of topics we want to pick up?
Otherwise, I think we’re about there.
Yeah, tons of stuff, but as you mentioned, we basically ran out of time.
So, thanks a lot for joining.
And it was really a valuable and interesting discussion and hope to see you again one day.
Well, thank you.
It was a great discussion.
I was really happy to be on this with you.
Yeah.
Thanks a lot.