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.
Sorry for the German commercial at the very beginning.
So this time it’s going to be with Cope about Software-Architektur, what it really is about.
So Cope, do you want to say a few words about yourself first?
I’ll try to keep it simple.
So I’m originally from the United States, but please do not associate me with their current politics.
I’ve been living in Denmark for about the past 20 years and live here on the far west coast where we have four horses and a wild cat who visits us every day.
I’ve done a lot of things in my career.
I started as an electrical engineer, went on to computer science, a lot of software stuff, early on object-oriented programming, and then more to the human side, to organizational issues, process, done a lot of Agile stuff, Scrum stuff.
And what we’re talking about today is really the cross-section between the human side and the technical side.
I mean, architecture is, as we’re getting into, it’s really as much about people as it is about the technology.
So it’s kind of a synthesis of where I’ve been around the world.
Mm-hmm.
Yeah, and we met, like, we tried to figure it out, like, 15 years ago at Jaguar or GoToCon, a conference in Denmark.
So yeah, that’s our history.
So I should probably say a few words about why we are doing this episode.
The reason is that I wrote a blog post about dependencies and how they are relevant for software architecture, and Coop commented on this blog post.
And I found those comments quite thought-provoking.
So therefore, I thought that we would take the discussion here and make it sort of public.
So that’s basically where we’re coming from.
So I will, first of all, try to sum up the blog post.
It’s actually related to one of the episodes that I did here in German on the stream.
So I will also provide the link to that episode if you want to see it in German.
And it’s also based on an English article.
And basically, what I wanted to say in the blog post is that dependencies are quite important for software architecture.
And in my opinion, if you want to change a system, the changes have a blast radius consisting of the stuff in the software that will be influenced by the change.
And the reason why we have that is because things inside a system are dependent on one another.
So therefore, if we change something, everything that depends on it might be influenced in one way or another.
And I would consider this a bad thing because it means if we want to change the system, things become complicated and software needs to be changed.
So therefore, we want to reduce that blast radius.
One of the ways that you can do that is by doing black box stuff, like you would only depend on the interface, not on the implementation.
Black box is something that is not transparent as opposed to white box, which should probably be called a transparent box.
And this goes back to the concept of information hiding, where you would say, well, every information that I hide, like in this case, the implementation, is information that I can change freely.
So if I only expose an interface, I can change the implementation as long as the interface stays the same.
The main point that I wanted to make in the blog post and that I sort of stole from that article is that there are different types of dependencies.
So the example that this article gives is, let’s assume that I have a dependency on Google Analytics.
So I can put in an abstraction layer.
And now I’m independent, or am I?
Because if that Google Analytics stuff provides new features, that’s actually beneficial to me.
So changes do influence me.
And there might be other problems.
So for example, if my system is badly written, it might be that the performance of my system depends on the performance of Google Analytics.
Because if I provide those analytics, I’m waiting for those analytics to be processed.
And that wait time is something that makes my website slower.
And then I do have a dependency.
It’s just that I can change the code freely because I’m independent from the implementation, but still there is an influence.
And that is actually the point that I tried to make.
And the other point, and we seem to agree on that, is that if I introduce a message bus, I provide anonymous communication.
So I don’t need to know or I won’t know who receives the messages from the send.
That’s not decoupling.
It just means that I’m not sure who I will influence.
The influence is still there.
So that’s pretty much the sum up of that blog post.
I’m not sure whether you want to add anything.
No, that raises a bunch of sparks in my mind.
So that’s a good start.
Okay, so do you want to talk about those sparks?
Again, this is a 10-hour presentation.
We’re going to try to compress it into one hour.
So I can come at this from several perspectives.
First of all, history has shown that all of this hope about separating concerns and managing things in terms of dependencies doesn’t work.
The most recent example I saw was a LinkedIn post, and Don, I wish I’d kept track of it, where someone had done a study on microservices, which are supposed to be the epitome of independence.
And they discovered, well, no, they’re not.
And they gave three or four reasons why.
One of them that I do remember is reuse, that if there’s some common logic across all of them, I have to replicate it in all of the copies, unless I want a dependency between two parts.
And a host of other things that said, I mean, this notion of trying to manage dependencies is just hopeless.
Managing dependencies is probably an honorable goal, but I want to raise this to a level of just being knowledgeable about them.
I told you I’ve been cogitating on this for the past few days, and we’ve kind of come to some insights.
And one of the insights is pretty pessimistic.
And it goes back to one of the things I said on my blog, which is recently I’ve been really inspired by another Danish guy named Peter Naur.
He’s dead now.
His son is still around.
But he said that the essential binding force in constructing software, and this is very closely related to architecture, is what he calls a theory.
So the team has a theory.
By theory, I don’t mean Dijkstra kind of stuff.
I mean, they have a way of explaining why things are the way they are.
Why is this line of code here?
Can you tell me why this line of code is here?
Can you tell me what happens when I change this line of code?
And the people have been with the system long enough that they just know.
And we can go very deep with this.
There’s something very timeless and philosophical about this.
I don’t know if you’ve ever read Zen and the Art of Motorcycle Maintenance.
No, actually not.
But I know that the book exists.
Yeah.
One of the themes is, I mean, he has a problem with his motorcycle.
I mean, he knows motorcycles pretty good, and he takes it to a mechanic.
And the mechanic who’s been working on these things all his life, I mean, it’s just like magic.
I mean, he does a welding of aluminum.
He said, no, welding aluminum is impossible.
Well, no, this mechanic knows how to weld aluminum.
There’s just stuff you got to know.
And I think this whole game of managing dependencies has some very interesting origins, and those are instructive.
And once you understand the origins, I think you start to question a little more why it’s there.
So this is all about complexity, right?
And there’s two kinds of complexity.
There’s essential complexity.
I mean, we’re solving complex problems.
Software is the most complex stuff that human beings have ever made.
It doesn’t matter how you slice it up.
It will still be complex.
And there’s this belief that if you just choose the right paradigm, there will be a partitioning that makes it simple.
And it’s simply not true, because the complexity is not hierarchical.
It’s network.
Then we choose a wrong partitioning, and that makes things worse, because it adds dependencies that weren’t there in the first place.
And that’s called accidental complexity.
So all right, we can kind of look at a thing and say, well, most of the relationships fall into this kind of shape.
And so if we go in with this shape of knife, then we can, for a first cut, we can kind of reduce the dependencies between parts.
So when you cut up a chicken, you know what size of knife to use to cut into the joint, right?
You don’t use a big hatchet, unless you’re Chinese, and they don’t care if there’s bones and everything, right?
That’s their style of cuisine.
So the point is, is that if you start analyzing things in terms of dependencies, why did we do this?
And this comes out of stuff, you know, 30, 40, 50 years ago, when it cost a lot to regenerate software.
And if I made a change one place, and some other place depended on it, then I’d have to recompile that.
And that would take, you know, hours, days, weeks.
I’m not making this up.
I mean, I had a client who had one month to regenerate the entire thing.
This was 40 years ago.
We aren’t in that world anymore.
Another thing they did in that world was, as you said, I’m going to add an abstraction layer, or a message bus, or things like that, and reduce the complexity.
And there’s something you said in the intro here, which is, you know, I’m only going to depend on the interface.
All right, so you’re depending on the interface.
The interface is the truth.
And I’m going to change the implementation without changing the interface.
So I don’t change any dependency.
Well, if the interface really contains all the information, and I use the term instructively, about what that thing does, then changing the implementation is going to change the interface.
Otherwise, the interface is lying about the implementation.
Abstraction is evil.
Abstraction means throwing stuff away in the interest of focusing on something else.
And we need every bit of information we can get.
You’re throwing away dependencies and creating those APIs and creating those interfaces.
So this whole thing about managing APIs, and therefore things like microservices, is total crap.
It’s a hope.
And it gives people a vocabulary and kind of a cultural context in which to work.
But it is not a deep theory about what the relationships between parts really are.
It raises it to the level of compile time dependencies, usually.
And that’s usually what people mean.
And I know you mean more than that.
But very few software engineers focus on that.
So I prefer to use the term relationships between parts.
Because dependencies, too many people think of, you know, good old make or configuration management.
And it’s much, much more than that.
And may I ask one question?
So I mean, so the sentence that you wrote an email to me discussing the blog post, and there was one sentence that sort of made me think, and that was the sentence where you said that everything depends on everything.
And I was like, well, that can’t be possibly true.
But in a way, it’s obviously true, because we build a system, and in the system, everything in some way or another depends on everything.
And therefore, I can see why you’re saying that managing dependencies is sort of a doomed approach.
However, at the same time, the fundamental problem that I see and that I think software architecture tries to solve is, we are building, as you said, a slot.
We’ll see.
So we are trying to build these huge systems.
And these huge systems are beyond the understanding of a single human.
So somehow, we need to be able to change these systems, even though one human can’t understand all of the system.
So therefore, we have to have a way to limit the knowledge.
And therefore, we have to be able to reason about the system, and at least neglecting some of these dependencies, not caring about them.
And I think that’s actually fundamental to software architecture.
So I guess the point that I’m trying to make is, yeah, you’re right, everything depends on everything.
But if we only can change a system by thinking about everything, we can’t build software because software is too complex.
So therefore, we have to ignore some dependencies, and we have to figure out which are the ones that we can usually ignore without too much risk.
And I’m wondering whether you would agree or whether there’s anything I’m missing, because I think that’s actually fundamental, right?
At the end of the day, I’m talking about information hiding, the stuff that Parnas was talking about, and I think it’s the reason why we care about dependencies.
So I would come at that whole argument from a different perspective.
And part of it is kind of, you know, wishful thinking and theoretical, part of it is real.
So number one, you’re talking about large systems.
And of course, everyone always asks, well, what do you mean by large?
And the obvious stupid answer is lines of code, which is ridiculous, because I mean, systems I see now, which are tens of millions of lines of code we could do in 48 kilobytes back in 1973.
I would argue a large system is a system that multiple people need to work on.
Okay, but the question is, why?
And again, in taking these walks and thinking about things, the past few days, there have been a number of innovations in software engineering.
Let me take one example, which is set-based design.
So set-based design says, instead of doing the big design up front with an architecture, you build three of them in separate efforts, and then you have a bake-off, you compare, and you take the best one, but you only change some things.
Okay, so maybe you change the database technology, and you try three different databases.
Okay, and then, okay, you pick the winner.
Now you do the next cycle, and you change fewer things, but with more alternatives.
And you do this four or five times, and in the end, you have an implementation.
I thought, yeah, that’s pretty clever.
That really works.
Google does all new products this way.
And there are studies that show it’s actually cheaper than coming back and fixing up your mistakes.
And then I found out where it comes from.
Where it comes from, like a lot of good things in our world today, is Japanese industry.
The Japanese instituted this because they hired people who were not domain experts.
And so instead of just knowing what the right alternatives were from their experience, and from engineering knowledge, and from knowing the discipline, they had to learn.
And the set-based design was a learning activity that took them through the alternatives, so they’d have the information to make the right decision.
So I think the fact that we have many, many, many people working on things today is a sign of the fact that we hire people en masse directly out of university with no domain knowledge.
And now we come back to Peter Naur, who talks about this theory building.
And one of the things that I discovered in some walks I was taking about a year ago, this was for preparation in a keynote in Romania, there’s all these things that have come together.
And different people have talked about it in using different vocabulary.
Let me see if I can find my notes here.
But if you look at a lot of the modern reasoning on what the problems of software are today, Peter Naur says the team doesn’t have a theory.
Jesse Watson from Amazon says the team does not have deep context.
Vitruvius, the original architect, says architects are armed at all points.
Deming talks about a system of profound knowledge.
Alexander talks about the whole.
Weinberg is talking about systems thinking.
All these things are the same.
And all this fascination with APIs and dependencies is a crutch that compensates for not fixing the problem.
Now, I’m an idealist.
And I’m going to say, here’s the problem.
So great.
Let’s incrementally move towards solving that problem.
Whereas stopping at managing dependencies and having all kinds of tools that do that and analyze this cuts off the path to evolution.
You stop learning.
You stop changing.
And you get stuck in a local optimum.
So I think the point that I understand from what you’re saying is that, in a way, we are building software and it’s a learning experience.
So we are trying to build this theory that Naur is talking about.
And it’s something that the team cares about.
If that is the case, first of all, I would argue that we seem to agree that it’s a team effort, right?
Because it’s different when, okay, so we are building large systems in the sense that a team needs to take care of it.
And I would argue that it’s not because we are not smart enough, but it’s because we are really trying to build systems that one person cannot possibly build by themselves.
So I would agree about that.
So it’s a learning experience.
And I think it’s something that a team does.
But the other part of this is why are we building large systems?
And again, this goes back to the tradition, all the way back to Bismarck in the 19th century and German hierarchies and command and control and making sure that running my business, I’m going to be able to organize things and orchestrate everything.
In contrast with object-oriented programming, for example.
So in object-oriented programming, there is no top.
And the reason that Alan Kay says there is no top, and by the way, no dependencies, is because the complexity is intrinsic.
So he compares an object with being like a cell in biology.
I mean, a cell does not know about the other cells around it and the things it’s interacting with.
It just has its responsibility.
And these things communicate with each other.
Even plants communicate with each other through their roots.
There’s no single global design that ties them together.
But the paradigm is such that if everyone is a good citizen, and acts according to reasonable expectations from the outside world, and learns, that the system will work.
And so we have telecoms that are built from this more independent parts.
I mean, when I was at AT&T, we tried to build the hyper-elastic switching system, the 5ESS, right?
And it was a local switch, it was a digital switch, it was an analog switch, it was a packet switch for crying out loud.
And they tried to put all of these things into one package.
Why?
Because AT&T was a big hierarchical company.
How big, you ask?
How many people do you think worked for AT&T when I started there on the 11th of June, 1979?
How many employees?
At least 10,000, I would say.
One million.
Okay.
That’s quite a lot.
So this is, that’s a lot of people.
And yeah, I mean, you get a lot of people, you need to manage them the way an army manages things.
And the way that they were managing things was in terms of hierarchies.
This is what we’ve learned going all the way back to the Romans and probably earlier.
So you end up with redundancy.
And that’s a good thing.
I mean, it’s hierarchy.
I mean, so first of all, you asked the question why we are building these large systems.
I would argue that we are building these large systems, because if we build more powerful systems, it’s a competitive advantage.
So if we build the most successful, the most powerful e-commerce platform, we do have a commercial advantage.
And if we can do that because we can coordinate a hundred, a thousand, or whatever, a large number of people better than others, then we will build the better system that can handle more different, complex stuff.
No, you don’t.
Okay.
You can’t, making things bigger allows you, making things bigger gets in the way of handling more complex stuff.
You’re already over the threshold of complexity if you have five features.
There’s very little difference in the paradigm of managing complexity for five features in a hundred.
If you look at the interactions between them, and this is why Parnas’s modules and the whole notion of design secrets falls apart.
So I gave a talk, this has been, wow, a zillion years ago, probably 40 years ago, analyzed Parnas modules and saying, well, the normal architecture story says that what we’re building and delivering is modules.
Now we don’t deliver modules.
We deliver features and features cut across modules.
And there are a lot of other things that cut across modules.
I mean, true architecture is essentially cross-cutting.
And I mean, building architects know this, by the way, buildings don’t build walls and floors and ceilings.
They build space.
What an architect designs is space.
They carve space out and the walls are just the things that define that space.
And this is what code is.
It defines the space and the space is the features that emerge from the interaction of those parts.
You’re always going to have complexity in terms of the interactions between the parts.
You’re also going to have another level of complexity in the interaction between the features.
You can’t do away with that.
And I did an analysis that if you try to make a design secret and hide it in a module and then make a very simple model about interactions between features and presume that features are your deliverable and use modules to hide those secrets, you end up with more modules in your system than there are stars in the known universe.
The whole paradigm is totally bizarre.
It’s totally insane if you get down to the real mental philosophical business things you’re trying to solve.
You don’t dominate your competition by making a system more complex.
You dominate the competition by meeting your end users’ needs.
So what did Apple do?
I mean, plot your iPhone, right?
How many apps do you have on your iPhone?
How many of them have you never opened?
But wow, they scaled that thing.
It’s big and you must be happy because it’s big and has all those apps that you’ve never used.
No, this isn’t how you make end users happy.
So what you’re saying is that the whole notion of dependencies is sort of doomed.
You also seem to be saying that large teams are probably not a good idea.
So how would you do a project in general?
Would you limit the number of people that would work on the project?
Like have it just one two-pizza team or how would you do that?
So, I mean, I do not have a pat answer.
I’ve currently been reviewing a book manuscript by a guy here in Denmark.
It’s a very clue-y book.
I expect it’ll be out next year.
And he answers all the kind of questions that I already have discussed, but this question he leaves open at the end.
Now, I have some ideas on what the answer might be.
And I mean, it starts with this, okay, everything in the universe depends on everything.
I mean, Christopher Alexander says that, right?
But what you do is, okay, you focus on the things that are most coupled to each other.
By the way, Constantine’s original definition of coupling and cohesion was purely lexical.
I know this.
He told me firsthand.
He gave me a tutorial on what coupling and cohesion are.
It is, okay, this function refers to a symbol in some other function or a data variable in some other module, and that’s coupling.
And the degree to which they refer to themselves is cohesion.
So when people, you know, in the Constantine sense say coupling cohesion, that’s what they mean.
Oh, one of the things I should have looked up.
There’s another Japanese guy who has a quote that says the maintainability of a system is proportional to the degree that its parts are coupled.
And the reason for that is if I make a change in one place, yes, it is going to have repercussions somewhere else, because, you know, everything is connected to everything.
If I have a dependency, that is a cue to where else I need to go and make it a coordinated change.
If I don’t have that dependency, I don’t have a clue.
Okay, so that means that what you’re advocating is to have explicit dependencies, and this is why a message bus that hides those dependencies or events are not a good idea.
Is that a rule that you would subscribe to?
Well, kind of, but again, there’s, this is a spectrum.
And I mean, the Japanese talk about three levels of mastery in the Budo, Shu, Ha, and Ri.
So at Shu, okay, you’re doing the traditional software engineering thing, and partners, modules, and measuring dependencies.
What you just said is Ha.
Okay, it’s one level of learning, where I’m saying, okay, let’s stop pretending that we can hide dependencies with buses and APIs.
And let’s, and the third level at Ri is, you just know.
And this is premises theory.
People understand the system well enough, or this is what I’m struggling with right now is this funny English word, intuition.
It’s an interesting word.
So in a good architect has intuition about what to change.
And I mean, in working on my code, I’ll have an intuition, gee, I wonder if this thing over here is maybe causing this problem.
And I’ll go look, and in about 50% of the time, I’m right.
And so there’s this informed intuition that comes from long-term exposure to the domain, to the code, to the other members of the team, of knowing who knows what, of having team discussions.
The dialectic among team members, where that discussion is exploring different dark corners of the architecture are tremendously productive in uncovering these things, much more than sitting with an impact of change analyzer that’s trying to figure out what the dependencies are between this module and that module.
It’s about people.
It’s about mental models.
It’s about that theory.
Yeah.
And that, by the way, is something that I would totally agree that at the end of the day, the question should be, or if I should rephrase it, at the end of the day, the question should be, can the team or whoever builds the system actually change the system?
They might have a way to change the system, even though the dependencies seem to be, well, messy, I would say, or whatever you want to call them.
Because of that, you call it intuition, or you could call it the theory that Naur is talking about.
And then it becomes an effort of the team to actually change the system.
And it’s not really about the dependencies, but it’s rather about their skill and how used they are to the system.
I had a friend, she’s an architect in Chicago.
She does building inspection.
She says, architecture is all about control.
And I think the reasons that things move against a stable architecture, I mean, we’re all told we want a stable architecture because that gives you control.
Everyone feels they have control.
Managers, marketing, developers.
I have a friend named Dave Smith.
This is OTI Dave, founder of OTI.
It was a small talk company back in the 80s.
He’s a venture capitalist, and he goes around and he starts up new projects.
So the way he starts up a project is they build a prototype, and they throw it away.
And they throw it away.
Then they build the product and throw it away.
Then they build the deliverable and release it.
Release one, release two, release three, and throw it away.
Release four, release five, release six.
They throw the code base away.
Code is a liability.
Dependencies are about code.
Forget the code.
Keep the theory.
That’s what’s expensive.
I mean, he’s running a business this way, and it’s a perfectly financially viable way to run a business in a highly complex area that’s evolving.
What it carries over from release to release is the team’s knowledge.
Now, the reason we can’t do this is because teams are not stable long enough.
This has to do with poor work environments, management, and all those kind of things.
I think that’s the paradigm shift to be focusing on is shaping the software industry around stable teams, hopefully around some domain where they can develop deep expertise.
That’s the problem.
So, talking about that point, I think there is one thing that I would strongly agree with, and that is that the learning experience and the theory is probably more important than the artifact.
To me, this is something that I also see in other cases, like if you have a design session, and you’re working on the design, whatever that is, like some artifact, you can throw away the artifact afterwards, and you still have a huge benefit because you talked about it, and you have that common idea, and you had that learning experience.
So, I would agree concerning that.
However, you could conclude from what you just said that because we can’t have stable teams because people change jobs, and maybe even you don’t want to rely on stable teams for business reasons because you want to be able to, you know, the truck factor where one person leaves the team, and then the team has a problem is considered a risk.
So, from a business perspective, you want to have a team where everyone is replaceable.
Then you might want to do the second best option and care about dependencies.
Does that make any sense?
I mean, what you’re saying is I want those stable teams.
What I’m saying is I do see the point, but you probably can’t have them.
So, then we go to the second best option, which is trying to manage dependencies.
I hear this coming from managers who don’t know how to manage stable teams or who have accurate environments where people leave, and those managers ought to be fired.
The problem is with management and work environments that cannot make an environment where people want to stay.
I mean, I copied a tweet here from Twitter some time ago.
So, Super Mario Brothers.
Very old program, right?
1985.
All those five people, four of them worked on Super Mario Brothers Wonder.
Which is the latest version, I presume.
Which is the latest version.
Now, number one, Super Mario, that’s a pretty darn complex program.
It’s real-time, and real-time is real.
I mean, it has to move in response to your clicks on the joystick and so forth.
It’s reliable.
It can’t lose data because it runs for days and days and days and days.
It has to collect garbage perfectly.
It can’t crash.
I mean, this is some of the toughest software built on the face of the earth, okay?
And it’s tremendously complex.
How many levels?
Five people, and that team stayed together for 40 years.
Now, Nintendo can do this.
AT&T could do this.
AT&T kept, I mean, it took eight years or 10 years to build the one ESS switch.
They kept the team together for that long to figure out how they did it.
I went and I interviewed one of the people who worked on it.
He had 50 years with the company.
Not 50 years of experience, 50 years with the company.
So, there are cultures that can do this.
Yeah, and I mean, in particular, the Japanese culture, where you basically go to one company and stay there for the rest of your life, maybe supports that.
Here is, I think, an interesting thought by Patrick Steyart, I think.
I know Patrick.
Patrick’s a little colleague of mine from Belgium.
Hi, Patrick.
So, I hope I said the name correctly.
So, what he says is, within organizations, what he says is, within organizations, stable teams have created huge integration problems because people cannot swarm to relevant problems.
What do you think about that?
I don’t understand the statement at all.
I mean, the fact that a team is stable doesn’t mean it can’t swarm.
It has to be small to swarm.
I mean, swarming basically means that the entire team is working as one mind on one, let’s call it, feature at a time.
I don’t know why a stable team can’t do that.
By the way, what I mean by stable team is that they’re not switching jobs all the time.
Their responsibilities from minute to minute and working on the product are very unstable.
Right now, I may be working on the database and five minutes from now, I’ll be working on the UX.
In that term, there’s instability.
From the outside, a swarming team, that is a team with a whip limit of one, looks chaotic.
To the team itself, based on their theory or what they know about each other or the non-verbal cues or the shared artifact cues, they know what they’re doing.
I simply do not understand the objection at all.
Maybe this is a confusion in terms, but no, I mean, I do not see that people coming to the same place and working with the same team every day has to do with that problem.
I don’t understand that at all.
But so what you’re saying is that, and I mean, that’s also probably the example that you gave with Super Mario, that what the team works on might be different.
But then, I mean, you said that the team worked on the original version of Super Mario and is now working on the latest version and has been working on, I assume, each version in between.
So what they are working on is changing.
So that means that they have to have sort of unlimited knowledge and have to sort of understand everything.
And then that seems, well, hard in a way.
Again, it limits probably what we can build in terms of systems.
No, I don’t buy that argument.
So number one, the knowledge is, of course, not unlimited.
And you’re always still learning things.
But you want to know what you don’t know.
And you want to know when to stop and pause as a team and say, okay, we need to think.
And swarming in terms of bringing people together from different teams.
No, there’s one team.
Why are you starting with a presumption that’s set up for failure?
You don’t bring people together from different teams.
You have one team.
So you’re just commenting on what Patrick said.
No, no, no.
So Patrick, yeah, we need to have a talk about what swarming means in the Toyota production system.
You don’t bring together people from multiple teams.
So no, I mean, this is not a problem.
So what he’s saying is swarming in terms of bringing people together from different teams, because the demand cross cuts the team structure.
So I know the team.
Okay, this is this is a key point, because in the old days, again, we want control, and we want stability.
So stability is another term we’ve avoided, but it’s very, very important.
So in the architecture is as it is, here it is, you know, all documented in UML.
And now we can have our, our organization chart follow that this is called Conway’s Law.
And the structure of the team organization reflects the structure of the software.
The problem is, and Patrick has kind of hit the nail on the head, where he says demand cross cuts the team structure.
Well, it does if your teams are structured wrong.
And the way we structured our teams, according to modules, was not the right way to structure them.
Because that isn’t the structure of the demand.
The structure of the demand is features.
So what is a scrum team?
A scrum team is not organized around a module, it’s organized around a feature.
So you’re aligning the demand with the team structure.
So the team is working on something of value together all the time.
Now, the usual, the usual pushback on this is, oh, my gosh, then people need to know a lot.
Yes.
And this is why the theory is important.
But in fact, it’s sufficient to start out with, you know, one person who’s an expert on testing, and another one who’s standby.
Another one is expert on database, and another is standby.
And I mean, I can point to myself as an example.
You give me a pile of sand and a pile of iron, and I can build this thing sitting here in front of me.
I’m an electrical engineer, I can design transistors, I can design ICs, I can design and have designed CPUs.
Okay, I’ve written operating systems, I’ve delivered application tools, I’ve managed teams.
Now, I’m old, and, you know, so that’s part of the story, I’ve had time to learn this.
I mean, what’s your excuse?
Oh, Patrick’s an academic, that’s his excuse.
Patrick’s going to get me for that, I know.
So let’s assume that we have a large system, and I would assume that people know specific parts of the code better, and other parts of the code they know little about.
So if we have, as you say…
Why?
Because, I mean, that’s sort of the basic assumption.
We’re building systems that no one can understand fully.
Otherwise, I mean, otherwise, if I’m just sitting in front of my machine and building software all by myself because I’m understanding all of the system, that’s, I would argue, not the problem that we have in the industry.
In the industry, we always have teams.
Well, if you can’t understand it, then you can’t use it.
And again, the problem is we’re building these huge, you know, hyper-elastic 5ESS systems that do everything, rather than building systems of systems.
So yes, I mean, there’s going to be dependencies between parts, but what I want to do is chunk them into autonomous parts.
And this is true at every scale.
I mean, this is what Alan Kay was trying to do with object-oriented programming.
And again, if we go back to Alexander, yes, everything depends on everything, but what I want to do is chunk things into team-sized chunks.
I mean, a good example, again, is they probably have a scale problem.
There’s this company in the Netherlands, and, I mean, if you’re a country that wants to go to war, you can go to them, and they will deliver you a missile guidance system and a radar system and a military command and control system.
I mean, it’s one company, and that’s the offering, you know, all these systems.
But the point is it’s multiple systems that interact with each other, and it looks from the outside like, you know, the legislature is going to approve one big chunk.
But you chunk it internally, and that reduces the accidental complexity.
The essential complexity is still there, but a good understanding of the domain is enough to master that.
If you don’t understand the domain, you shouldn’t be in the business.
So now you’re saying that, in principle, we can have, well, systems, and we can chunk them into systems of systems, and each of them are autonomous.
So what you’re saying is that we can have something that is composed of smaller parts and that they have limited dependencies, or are you saying something different?
It’s not that they have limited dependencies.
It’s that I want their dependencies to reflect the essential complexities.
These are the things I need to know about the business anyhow.
And so they’re not an artifact of the structure of the software or how I structure it.
They’re things that if I don’t know these, I’m out of business.
I want the dependencies to reflect that.
A lot of my career has been with Dave Weiss.
He was a student of Parnas, but smarter than Parnas was, and he’s really big into what’s called domain analysis.
So what a good product owner should do is analyze the domain, and it’s that knowledge that she communicates to the team.
That’s business knowledge.
And I run into this kind of ignorance in software all the time.
You look at the fad stuff, like extreme programming.
You go to Kent Beck.
Kent Beck says, okay, how do you build a bank, a banking system?
He says, well, you use a metaphor.
So a bank account is something to which you can add money and take money away.
It’s just a calculator.
Bullshit.
I mean, your balance is not something sitting on a disk or sitting in memory somewhere.
It’s a computation over an audit trail, and the main architecture of a financial system is this audit trail and a transaction log.
And so you have these ignorant people coming with a software engineering perspective and saying, oh, my gosh, it’s just a calculator, who lack the domain knowledge.
They lack the theory.
And the dependencies just go to hell in a handbasket.
So you’ve got to know about that up front, and that’s going to allow you to minimize the dependencies that come from the essential relationships between the parts.
So I would totally agree that getting the domain right and getting the split of the domain right is essential for building software successfully.
I mean, that goes without saying, in my opinion, or should go without saying, and really it doesn’t.
And I would also agree that the metaphor in extreme programming is very simplistic.
It’s not enough to really capture what the system should be about.
But what I’m a little bit confused by is, I mean, I could now say, okay, so here is my system.
I’m building modules according to what the domain tells me.
I would have that, whatever it is, what my domain tells me.
So you said there is an audit log.
So I have something that is called an audit log, something that is related to the domain.
And then I have dependencies between those modules, and I have software architecture now.
And I would argue that you have a pretty good software architecture because you have not too many dependencies.
It’s actually what you said, that this is a way to manage dependencies.
No, no.
Okay, so tell me where my misunderstanding is.
You don’t have accidental complexities.
Right.
What I want is I want to have as many dependencies as possible.
Okay.
So that if I make a change that affects something else somewhere in the system, the system crashes.
The test fails.
Red lights go on.
I want dependencies to be visible and manifest and to cost me a lot when I violate them.
And software engineers want their tests to pass.
They do exactly the opposite.
And they should be from the domain, not accidental?
Yeah, yeah, yeah.
And that’s the key point.
So you should be a friend of domain.
The problem is if you start off with a superficial knowledge of the domain or set-based design or domain analysis, these systems evolve, and they evolve into crap anyhow.
And this is why I said in the first 10 minutes, history shows that we don’t know how to foresee dependencies well enough.
This is why Dave Smith throws everything away every third release and starts over.
The point is you’re kind of stuck.
And I know this is very pessimistic, but I think that a lot of the software architecture talk is this Pollyanna hopeful thinking that, gee, we know how to take control.
We know how to be in control because we as humans are smart.
We’re smarter than software.
We know how to be in control.
And then they talk about architecture.
I’ve been going to conferences for the past five years, and there are people there like Neil Ford.
Neil Ford talks about what he calls architecture.
It’s not architecture.
It’s engineering.
There’s no theory.
There’s no space.
He’s talking about the bricks and the wall.
And he’ll spend a whole 45 minutes talking about this brick and this wall and how you should shape it.
And it’s like I’m sorry.
That’s not what’s killing us in software.
So let’s assume – I mean sticking to that banking problem, let’s assume that we have a good understanding about the domain.
So you said that a bank account is an audit log, and let’s assume that we spend some time working on that concept.
And we have figured it out.
Now what you said is – and this should be fundamental, right?
I mean bank accounts are a concept that has been around for like, I don’t know, hundreds of years, probably since the Middle Ages even.
So it should be something that is pretty stable.
Now what you said is that in your experience or your recommendation would be what Dave did, which is throw away the system, build it anew.
So in a way you’re saying that even though we can come up with this idea about what a bank account is or whatever it is that our domain is and we should model that.
This model is so wrong that we should rather throw it away than try to make it valuable for the next iteration of what we are going to build.
Why?
I mean as I said, it shouldn’t be possible to figure out what a bank account is or whatever your domain is.
So I think this throwing it away applies to the situation that the Japanese saw in manufacturing where you don’t have the domain expertise.
I agree with you.
I think you have the domain expertise.
I mean every banking system looks like every other banking system.
And I mean it’s only capitalism and this pretense of competition, which by the way I think is a good thing because it encourages people to try things in different ways.
But everyone has to invent the wheel again themselves to have theirs.
This is my system and it’s better than yours rather than building on the knowledge of each other.
And by the way, this is one of the Japanese advantages over the West.
I mean I toured a Toyota factory once and there was a stock of GM engines sitting there.
Okay, so they’re building on the knowledge that GM has put into engine development and using that.
And I’ll find these partnerships in Japan and in general I’ll find them in other industries.
In software, we only have it at the level of commodities.
So you know the string library, the operating system and so forth.
It’s not at the level of strategic business value.
Whereas an engine, that’s strategic business value.
So I think – Well, I mean you can buy a license of SAP and it actually has some business value baked in because it tells you how to run your company.
SAP is – Because all the processes are there.
And I mean it’s not limited to SAP.
It’s just ERP, CRM and whatever, all these standard software systems that we have in the business world.
They actually have some business value baked into them.
Absolutely.
The value proposition that they have these standardized business processes that you just have to adapt.
I had never thought of that.
That’s actually maybe a very good example.
One thing I want to do is look into this after we’re done here.
So there’s good news and there’s bad news.
The good news is what you said, is there’s a lot of stuff there.
The bad news is that if I get SAP, I’m not going to touch that thing.
I have to go out and hire a small team of special wizards who specialize in coming in and customizing SAP for the purposes of my business.
I mean no one goes into SAP and comes out alive unless you’re one of these wizards, right?
What’s interesting is it’s a relatively small team of wizards who can go in and tweak SAP to make it dance to my tune.
I don’t need hundreds of people.
So there’s an interesting story there.
So I have to admit that today and yesterday I was just reviewing some material that a colleague of mine, Hans-Jörg, came up with for our ERP services stuff.
And one of the points that he really tries to drive home is that you should adopt the standard business processes that the ERP system gives you.
So it should be the other way around.
You should dance to the tune of SAP because they have some standard processes and chances are that those processes are better than the ones that you have.
Which is in a way what you just described.
It’s sort of knowledge sharing about the domain, right?
Because most people in Waldorf, they basically sit around and figure out how a company should ideally work.
They bake that into the software.
Once you buy the software and you just use it without a lot of customization, you get those processes for free.
That’s sort of my understanding.
Yeah, yeah, yeah.
That’s a really interesting example.
Okay.
Okay, great.
It goes back to these discussions that Frederick Brooks also had that standard software is one of the ways to maybe get a lot of magnitude more productivity.
This isn’t about productivity.
Productivity is the number one cause of waste.
All those apps on your iPhone came as a result of people focusing on productivity.
This is not about productivity.
It’s about value.
It’s about focusing on the end user.
So, I mean, an architect who says, I’m going to build tract housing of a thousand houses and focus on the productivity of the houses, I don’t want to go anywhere near them.
I want an architect who’s working with me and focusing with me to build my house.
My wife and I, you know, worked about six, seven years ago.
We built a new house here.
And she worked directly with the architect for weeks to design that house.
They were not concerned about productivity.
They were not concerned about dependencies.
That’s a carpenter’s job.
I completely agree.
But if I look at the discussion that we are having right now also with AI, it seems that there is a lot of focus in the industry on productivity, how much stuff we put out.
And at the end of the day, if I look at AI, sometimes even just the lines of code that are being generated.
So, what you’re saying makes a lot of sense, and it’s actually quite logical because at the end of the day, if you do some work, the question is how much value do you generate?
However, it seems to me that this is not what the majority in our industry thinks about.
So, do you have an explanation for that or maybe even a solution?
So, there’s a saw in the industry that started, you know, no one can ever be blamed for using IBM.
So, no one can ever blame a project manager who says, well, you know, I delivered this many million lines of code.
They can measure it.
And they believe it has value.
And this is why I’m trying to emphasize code is a liability, not a value.
The industry is starting to realize that en masse.
I mean, we started to realize that code is a liability, I think, 20 years ago.
But, I mean, there are still cultures that don’t believe that way.
And those, I’m afraid, are fueling AI.
In terms of actual value, I mean, AI is really alluring and deceptive and tantalizing.
People believe they’re 40% more productive.
I don’t remember the exact numbers.
There’s a very, very famous study where they took some AI people and said, how much more productive do you think you are?
And they said X.
They actually measured them and they were actually 20% less productive.
This is a very famous study.
So, no, I mean, please do not preach AI at me.
I mean, I’ve got the numbers.
I’ve got the studies.
I’ve got the publications.
I haven’t found a single AI publication that says this really did help and here’s the business results that we got from it.
But I have 20 or 30 that show here’s where it almost killed us.
Ford rolled out AI and found that their quality went to hell.
They pulled it back and they hired back all the people they fired and replaced them with AI.
That was three weeks ago.
My point is not so much about AI.
My point is rather that the popularity of AI points to a deeper misunderstanding about what software development actually is.
As you said, that it should be about business value and it should be about providing value to some customer.
And it’s not about generating – as you said, I mean this sentence about how software is a liability and the features are actually the asset.
I think that’s very, very important.
But I was wondering why we don’t realize that and if you have any idea how we can make more people realize that.
I mean this is obviously a first step because we talk about it.
But maybe there is more to it because if we get the industry to realize that in a broader scope, then a lot of discussions concerning AI, for example, might be a lot better.
I totally agree.
I think that’s a whole different podcast.
We can do that together.
It’s a whole other level of questions that are very, very serious questions about industry level down.
I think one of the key problems is that we’re very poor at measuring.
So number one, we don’t really know what to measure, so we measure productivity.
And number two, even though we do have things to measure, we don’t.
So I go looking for measures of X, Y, and Z that do matter and no one is collecting data on it.
No one is paying researchers to do this.
Researchers cannot make inroads into real projects to measure this kind of stuff and publish it.
So we have a dearth of data and it’s very, very hard to make progress when we don’t understand what’s going on there.
So we are a little bit over the hour that we wanted to fill.
So is there anything that you still want to talk about?
Is there anything that – any sort of final remarks that you want to make?
I guess the only final remark I’d leave with people is remember the shoe-ha remodel.
I mean you at least want to get to ha to encapsulate things, encapsulate the domain knowledge into things that are related in the domain.
But the real problem is organizational, it’s corporate culture, it’s keeping teams together to build this theory of knowledge over time.
I really think that that’s where the solutions lie with all of these pretend engineering hacks that we call architecture.
Set that as your goal rather than trying to manage numbers about coupling and cohesion or trying to just fool yourself and adding yet another layer of abstraction.
The industry is full of this.
Most of the design patterns from the Gang of Four are exactly that.
Just adding another level of abstraction, it adds accidental complexity.
We’ve got to get down to more basic systems understanding rather than just understanding how to program and how to use frameworks and how to buy a book and just blindly follow what it says.
Deming said there’s no substitute for a system of profound knowledge.
Yeah, I would agree and I think also concerning the – this is something that I find interesting with regards to the AI discussion as well.
I think software engineering and software architecture at the core are a problem around humans and a social problem and therefore I would totally agree to what you just said.
Okay.
Thanks a lot.
Thanks a lot for spending the time.
Thanks a lot for commenting on the original blog.
No, thank you.
Yeah, you’re welcome.
It was a pleasure and the next episode will be in German I’m afraid on Tuesday and we will talk about event storming and collaborative modeling.
So, this will talk about, well, how to make people collaborate with some techniques.
So, it’s probably a good add-on to what we discussed here.
Hey, everyone.
Eberhard knows event storming.
Come and see this.
You’ll get some good tips.
You can’t make people collaborate, but you can certainly incentivize them to do so.
Yeah.
Thanks a lot and have a great weekend.
Thank you.
Thank you.
Bye.
Bye-bye.