# Rethinking Software Architecture: Team Knowledge Over Dependencies

**Podcast:** Software Architektur im Stream
**Published:** 2026-07-24

## Transcript

So, willkommen everybody to another episode of Software Architecture on Stream.
Sorry for the German commercial at the very beginning.
So this time it's going to be with Cope about Software Architecture, 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.
Ich habe in Denmark über den letzten 20 Jahren gelebt, und live hier auf der westen westen, wo wir vier Horses und ein Wildcat besitzen uns jeden Tag.
Ich habe ein paar Dinge in meinem Leben gemacht.
Ich habe als Elektro-Engineer angefangen, habe ich ein paar Software-Einigungen gemacht, ein paar Software-Einigungen, und dann mehr auf den Menschen-Side.
Ich habe auch ein paar Dinge gemacht, ein paar Dinge gemacht, ein paar Dinge gemacht.
Und was wir heute sprechen ist die Konsequenz zwischen dem human- und dem technical- und dem technischen-Schein.
Ich habe auch eine Art, als wir in die Zukunft getrennt, ist wirklich nicht mehr über die Leute, wie es über die Technologie ist.
Es ist ein Synthesis von wo ich bin, um die Welt zu verändern.
Ja, und wir met, wir haben 15 Jahre alt, oder wir waren in der Konferenz in Denmark.
So, ja, das ist unsere Geschichte.
So, ich sollte wahrscheinlich ein paar Worte über warum wir hier machen.
Die Grund ist, dass ich ein Blogpost über Dependencies und wie sie sind für Software-Hitaktionen und Kup commented auf diese Blogpost.
Und ich fand die Kommentare sehr viel thought-provoking.
So, ich dachte, wir würden die Diskussion hier und machen es sort of public.
So, das ist basically wo wir kommen.
So, ich will, first of all, versuchen wir zu den Blogpost zu.
Es ist eigentlich related zu einer der Episodesen, die ich hier in Deutschland auf dem Stream.
So, ich will also provide den Link zu den Episoden.
If you want to see it in German, 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, ist, dass ich das Info anvergleichbar kann.
So, wenn ich nur eine Interfasse habe, kann ich die Implementation ändern, als die Interfasse ist, dass es die gleiche.
Die Hauptsache, dass ich in der Blogposte und das ich sort of stole von dem Artikel habe, ist, dass es da gibt, dass es verschiedene Typen gibt.
So, der Beispiel, dass dieses Artikel gibt ist, dass ich eine Dependenz auf Google Analytics habe.
So, ich kann in eine Abstraction Layer in Und jetzt bin ich independent.
Oder bin ich?
Weil wenn das Google Analytics stuff gibt, das ist eigentlich gut für mich.
So, die Veränderungen sind mir wichtig.
Und da gibt es andere Probleme.
So, zum Beispiel, wenn mein System ist, ist es, dass mein System die Leistung des Google Analytics verwendet.
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, dass wenn ich ein Message passen werde, ich werde anonymisieren.
Ich werde nicht wissen, oder ich weiß, wer die Messages von der Send.
Das ist nicht gut, das heißt, ich weiß, wer ich will, die Influencer ist noch da.
Das ist das, was ich nicht sicher, ob ich das Wort poste habe.
Ich weiß nicht, ob du etwas dazu willst.
Ja, es gibt ein paar Sparks in meinem Geist, so das ist ein guter Start.
Okay, so do you want to talk about this Sparks, oder soll we do it?
Well, there's, 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.
Ich meine, first of all, history has shown that all of this hope about separating concerns and managing things in terms of dependencies doesn't work.
I mean, 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 is 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 kind of come to some insights.
And one of the insights is pretty pessimistic.
And it goes back to one of the things I sent on my blog, which is recently I've been really inspired by another Danish guy named Peter Nauer.
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 Zenon, The Art of Motorcycle Maintenance.
No, actually not, but I know that the book exists.
Ja, ein Thema ist, ich meine, er hat einen Problem mit dem Motorcycle.
Ich meine, er hat einen Motorcycle-Klein.
Er hat einen Mechanik, und der Mechanik, der hat sich auf diese Dinge gearbeitet, ist es einfach so, wie magic.
Ich meine, er hat sich das Welding von Aluminium angenommen.
Er hat sich, nein, Welding von Aluminium ist unmöglich.
Well, no, das Mechanik kennt wie wie zu Weld Aluminium.
Es ist einfach, dass du das Thema, das du musst, und ich denke, das ganze Spiel des Manageigen Dependencies ...
Es hat einen sehr interessanten Orgins und die sind instructive.
Und wenn man die Orginschüsse ist, dann wird man sich fragen, warum es da ist.
So das ist all über die Komplexität, richtig?
Und da gibt es zwei Karten.
Da gibt es die Sensual-Complexität.
Wir sind selten complex Problems.
Software ist die größte Sache, das Menschen haben immer gemacht.
Es geht nicht um, wie Sie es auf den Schlechstuhl machen.
Es geht um, wie Sie es immer wieder machen.
Und da gibt es dieses Belief.
Das ist einfach nicht so, weil die Komplexität nicht hierarchisch ist.
Es ist ein Netzwerk.
Dann wählen wir eine falsche Partition, und das macht es etwas worse, weil es sich nicht mehr gibt.
Das heißt, dass die Komplexität nicht hierarchisch ist.
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, you know, 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...
A big hatchet, unless you're Chinese and they don't care if there's bones in 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 their 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.
ist, dass es evil ist.
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 in creating those APIs, in creating those interfaces.
So this whole thing about managing APIs and therefore things like microservices is total crap.
It's a hope.
Und es gibt Menschen ein vocabulary und ein culturales Kontext in welchen zu arbeiten.
Aber es ist nicht ein deep theory über was die relationships zwischen parts wirklich sind.
Es gibt es zu den levelen von compile-time dependencies, usually.
Und das ist usually was Menschen, und ich weiß, Sie mehr als das.
Aber sehr viele Software Engineers focus auf das.
So ich prefer zu benutzen die termen relationships zwischen parts, weil dependencies, too viele Leute...
Think of good old make or configuration management.
And it's much, much more than that.
May I ask one question?
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 built a system and in the system, everything in some way or another depends on everything.
So, 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, Drumroll!
und zumindest nicht mehr die dependencies, nicht mehr über sie.
Und ich denke, das ist eigentlich fundamental für Software Architecture.
So, ich denke, das ist die Punkt, die ich mich zu machen mache ist, ja, du bist richtig, alles ist, aber wenn wir nur ein System verändern können, über alles, wir können nicht mehr über alles, weil es nicht mehr so ist, weil es zu komplex ist.
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.
Und part of it is kind of 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 systems I see now, which are tens of millions of lines of code, we could do in 48 kilobytes back in...
Ich würde sagen, ein large system ist ein System, dass viele Leute müssen arbeiten.
Okay, aber die Frage ist, warum?
Und wieder, in den Gedanken über die Worte, in den letzten Tagen, in den letzten Tagen, in den letzten Tagen, in den letzten Tagen, in der letzten Tagen ein paar innovativen in Software Engineering.
Ich nehme eine zum Beispiel, die ist Set-Based Design.
Set-Based Design sagt, dass sie die große Design-Front mit dem Architektur, 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.
Ich dachte, ja, das ist ziemlich clever.
Das wirklich funktioniert.
Google macht alle neue Produkte dieses Wunsch.
Und es gibt studies, die es eigentlich cheaper ist als zu kommen und zu kommen, und zu fixieren.
Und dann habe ich gefunden, wo es kommt, wie ein paar gute Dinge in der Welt heute ist, ist die ganze Welt der Welt.
Die Japanese instituten dieses, weil sie nicht die Leute waren, die nicht domain experts waren.
Und so, instead of just knowing, 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 Wir hireen Menschen, en masse, direkt aus der Universität, mit keinemannemannemannemannemannemannemann.
Und jetzt kommen wir zurück zu Peter Nauer, der spricht über diese Theory Building.
Und eine der Dinge, die ich in den Walken habe, ich war ein Jahr, das war für die Preparation in der Keynote in Rumänien, ist, dass alle diese Dinge, die haben zusammengekommen.
Und verschiedene Leute haben über das in den verschiedenen Vokabeln.
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 Nauer 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 Noah 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 Es ist nicht weil wir nicht smart genug sind, sondern weil wir wirklich versuchen, zu bauen systems, dass eine Person nicht möglicherweise bauen.
Ich würde das agree.
Es ist ein Erfahrung, und ich denke, es ist etwas, dass die Team ein Team macht.
Aber die andere Partie ist, warum wir large System bauen?
Und wieder, das geht zurück zu der Tradition, all die zurück zu Bismarck in der 19th Century.
und German hierarchies und command and control und 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...
Der Komplexität ist intrinsisch.
Er comparet ein Objekt mit einem Cell in Biologie.
Ich meine, ein Cell hat nicht über die anderen Cells, die es um den Dingen mit.
Es hat es um die Verantwortung.
Und diese Dinge kommunizieren mit einem anderen.
Even Plans kommunizieren mit einem anderen durch ihre Roots.
Es gibt keine globalen Geschenke, die sie zusammenküren.
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...
Die 5ESS, was ein digital switch.
Es war ein analog switch.
Es war ein Packet switch, für crying out loud.
Und sie hat alle diese Dinge in eine package.
Warum?
Weil AT&T war eine große, hierarchische Firma.
Wie big, du sagst?
Wie viele Leute, die ich war für AT&T, wenn ich da war, auf der 11.
Juni, 1979?
Wie viele employees?
At least 10,000, ich würde sagen.
Okay, that's quite a lot of people.
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.
And 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 a hierarchy.
I mean, the...
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 100, 1000 or whatever, a large number of people better than others, then we will build the better system.
Das kann man mehr, mehr, mehr, mehr, mehr, mehr, mehr, mehr, mehr, mehr, mehr, mehr, mehr.
Du bist bereits über die Threshold von Complexität, wenn man fünf Features hat.
Es ist sehr wenig, in der Paradigm von Managung Complexität für fünf Features in 100.
Wenn man die Interaktions zwischen den Interaktionen Und das ist, das ist, das ist, das Parnas Modules und die ganze, die ganze, die Design Secrets, falls apart.
So, ich habe ein Talk, das ist, wow, ein zillionen Jahre, wahrscheinlich 40 Jahre, um, das Analyze Parnas Modules und gesagt, well, die normalen Architektur story says, was wir building und delivering ist Modules.
Now, wir nicht Modules, wir Delleure Features.
Und Features cut across modules.
Und da sind viele andere Dinge, die cut across modules.
Ich meine, true architecture ist, essentially, cross-cutting.
Und ich meine, building architects wissen das.
By the way, buildings nicht bauen, und floors, und ceilings.
Sie bauen space.
Was ein architect nennt ist, ist space.
Sie haben space.
Und die walls sind einfach die Dinge, die das space define.
Und das ist was Code ist.
Es definiert die Space und die Space ist die Features, die in den Interaktion zu den Parten entstehen.
Du hast immer eine Art von Complexität in den Interaktionen zwischen den Parten.
Du hast auch eine Art von Complexität in den Interaktionen zwischen den Features.
Du kannst du weg mit dem.
Und ich habe einen Analyse, dass wenn du eine Design-Secret und in den Modul machen, und dann eine sehr simple Model über Interaktionen zwischen Features, und die Features der Verlagerung sind, und die Modulen zu schützen, die Sie mit mehr Modulen in der System sind, als in der Known-Universität sind.
Ich meine, die ganze Paradigm ist totaler, totaler Bizarre.
Es ist totaler, totaler Insane, wenn du die reale, mental, Philosophical-Business-Things du hast.
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, okay, so what's the, I mean, so what you're saying is that the whole notion of dependencies is sort of doomed.
So, and 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 will 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 cluey book.
I expect it'll be out next year.
And he answers all the kind of questions that already I've discussed.
But this question he leaves open at the end.
Now, I have some ideas on what the answer might be.
Okay.
Er hat mir ein Tutorial, was Coupling & Cohesion ist.
Okay, das Funktion ferns zu einer Symbol in einer Funktion oder eine Daten Variable in einer Modelle.
Und das ist Coupling.
Und die Degree zu welchen sie sich zu beherrschte, ist Cohesion.
So, wenn Menschen, in der Konstantin-Sense, sagen Coupling & Cohesion, das ist, was sie.
Oh, eine der Dinge, ich sollte es auf, da ist ein anderer, ein anderer Japanese-Gesie, 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 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, this is a spectrum.
I mean, the Japanese talk about three levels of mastery in the Budo, Shu, Ha, and Ri.
So at Shoo, okay, you're doing the traditional software engineering thing and Parnas 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 the third level at REE is you just know.
And this is Parnas' theory.
People understand the system well enough or Das ist das ich mit dem Schleuch mit.
Das ist das lustige Englisch Wort.
Das ist ein interessanter Wort.
So ein guter Architekt hat, die Intuition über was zu ändern.
Und ich meine, in meinem Code, ich habe eine Intuition, ich habe, ich habe, ich habe, ich habe, ich habe, ich habe, ich habe, ich habe, ich habe, ich habe, ich habe, ich habe, und ich habe, und ich habe, und ich habe, und ich habe, und ich habe, und ich habe, und ich habe, und ich habe, und ich habe, und ich habe, und ich habe, und ich habe, und ich habe, und so, da ist, das Informed Intuition, das kommt von long-term exposure, zu dem Domain, zu dem 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.
Ja, und das ist, by die Seite, was ich das, was ich total, dass ich das Ende der Ende der Zeit, die Frage sollte, oder wenn ich es rephrase, kann der Team oder whoever die Systeme der Systeme, die Systeme, die Systeme, die vielleicht haben, die Systeme, die Systeme, die Systeme, die Systeme, die Systeme, die Systeme, die Systeme, die Systeme, die Systeme, die Systeme, die Systeme, die Systeme, die Systeme, die Systeme, die Systeme, oder was Sie, ich würde sagen, oder was Sie, weil Sie sie, weil Sie sie, weil Sie sie, weil Sie sie, weil Sie sie, weil Sie sie, weil Sie sie, weil Sie sie, weil Sie sie.
Das ist die Theorie, die Noah ist, und dann wird es ein Team verändern, um die System zu ändern.
Und es ist nicht wirklich über die Dependencienz, sondern eher über die Skill und wie sie sind in der System.
Ich habe eine Freundin, sie ist ein Architekt in Chicago, sie machte eine Building Inspektion, sie sagt, architecture ist all über Kontrolle.
Und ich denke, die Reasons-Einheit sind, sind wir gegen eine Stable Architektur.
Wir sind alle gesagt, wir wollen eine Stable Architektur, weil das gibt es, dass du Kontrollverlust.
Manage, Marketing, Entwickler.
Ich habe ein Freund von Dave Smith.
Das ist OTI Dave.
Der Founder von OTI.
Er war ein Smalltalk company in den 80er Jahren.
Er hat sich gerade in den 80er Jahren.
Er ist ein Venture Capitalist und er geht um und er startet neue Projekte.
So die Art er startet ein Projekt ist, sie bauen eine Prototype und dann throw es weg.
Dann bauen sie die Produkt und throw es weg.
Dann bauen sie die Deliverable und release es.
Release 1, release 2, release 3, und throw es weg.
Release 4, release 5, release 6.
They throw the Codebase weg.
Code is a liability.
Dependencies are about code.
Forget the code.
Keep the theory.
That's what's expensive.
And 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.
Das ist die Frage, die Software-Infrieren, um die Stabilität zu haben.
So 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.
And 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.
und du hast das Erfahrung, so ich würde sagen, dass das.
Aber du könntest von dem, was du gesagt hast, dass wir nicht haben Stable Teams, weil Leute verändern, und vielleicht nicht mehr auf Stable Teams, für business reasons, weil du willst, weil du willst, dass du ein Faktor hast, Wenn man einen Team leaves, dann hat man einen Problem, ist es ein Risiko.
So von einem Business-Perspektive, wenn man einen Team hat, wo man sich alle verabschieden ist, dann muss man die 2nd Best Option machen und sich über die Dependenzen interessieren.
Das ist das Sinn?
Ich meine, was du sagen ist, ich möchte diese Stable Teams.
Was ich sage, ich sehe die Punkt, aber du kannst nicht haben.
So dann muss man die 2nd Best Option machen, They're 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 I mean, 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.
Super Mario Bros., ein sehr altes Programm, in 1985.
All diese fünf Leute, vier von ihnen worked auf Super Mario Bros.
Wonder.
Which ist die letzte Version, ich presume?
Which ist die letzte Version.
Nun, Nummer eins, Super Mario, das ist ein ziemlich complex Programm.
Es ist real-time, und real-time ist real.
Ich meine, es hat sich in Richtung zu verändern, die Klicks auf die Joystick und so weiter.
Es ist nicht möglich, es kann nicht verlieren, weil es dauert für Tage und Tage und Tage und Tage.
Es hat sich zu collectieren, perfekt zu werden.
Es kann nicht crash.
Ich meine, das ist ein der toughesten Software-Bilden auf der Erde.
Okay?
Und es ist sehr komplex.
Wie viele Levels?
5 Leute.
Und das Team hat sich zusammengelegt für 40 Jahre.
Nun, Nintendo kann das.
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 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.
Ja, und ich meine, in particular, die Japanese culture, wo du einfach nur eine Firma und bleibst da für den Rest des Lebens, vielleicht supports das.
Hier ist, ich glaube, ein interestinges Wort von Patrick Steyer.
Ich weiß, Patrick.
Patrick ist ein Kollege von Belgiung.
Hi, Patrick.
Ich hoffe, ich sage den Namen richtig.
Was er sagt, dass in den Organisationen, Stable Teams haben eine große Probleme entwickelt, weil sie nicht die Probleme können.
Was denken Sie, dass das?
Ich verstehe das nicht.
Ich meine, die Faktie ist Stable, nicht das heißt, es kann man nicht swarm.
Es muss man small zu swarm.
Ich meine, Swarming basically means, dass die ganze Team ist, als eine Mind auf eine, wir sagen es, eine Art, an einem, ein Feature, an einem.
Ich weiß nicht, warum ein Stable Team nicht das tun kann.
Was ich meine Stable Team ist, dass sie nicht die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die Zeit, die There's instability.
And from the outside, a swarming team, that is a team with a whip limit of one, looks chaotic.
But to the team itself, based on their theory or what they know about each other or the nonverbal cues or the shared artifact cues, they know what they're doing.
So I simply do not understand the objection at all.
Und vielleicht ist das ein Konfusion in Terms.
Aber ich sehe nicht, dass die Leute zu den gleichen Ort und mit dem gleichen Team mit dem ganzen Tag haben, das Problem hat.
Ich verstehe das nicht.
So was du sagen ist, und ich meine, das ist auch wahrscheinlich der Beispiel mit Super Mario, dass was die Team arbeitet, aber dann...
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 a setup for failure?
You don't bring people together from different teams.
You have one team.
So you're just commenting on what Patrick said in the comments.
No, no, no.
So Patrick, 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 teams of bringing people together from different teams because the demand cross-cuts the team structure.
No, the team...
Okay, 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 the architecture is as it is.
Here it is, you know, all documented in UML.
And now we can have our...
Our organization chart follows 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 pushback on this is, oh my gosh, then people need to know a lot.
Yes, and this is why the theory is important.
Aber in fact, es ist zu starten mit einer Person, die eine Experte auf Testing und eine andere Person ist ein Standby.
Eine andere Person ist ein Expert auf Database und eine andere Person ist ein Standby.
Und ich kann mich an, als ich an example habe.
Du gibst mir ein Pile von Sand und ein Pile von Iron und ich kann das Ding hier in front of mich bauen.
Ich bin ein Elektro-Engineer.
Ich kann Transistors.
Ich kann ICs.
Ich kann und habe 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 a 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...
Ich würde sagen, das nicht der Problem wir haben in der Industrie.
In der Industrie immer haben wir Teams.
Wenn man nicht versteht, dann kann man nicht nutzen.
Und wieder, das Problem ist, wir bauen diese große, hyper-Golastic 5-E-S-S-S-Systems, die alles tun, stattdessen zu bauen, als System aus System.
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.
This is a company in the Netherlands.
Und ich meine, wenn du ein Land, ihr könnt ihr zu einem, ihr könnt ihr ein Missile Guidance System und ein Radar System und ein Military Command und Control System.
Und ich meine, es ist eine Firma.
Und das ist die Offering, all diese Systeme.
Aber die Punkt ist, es gibt verschiedene Systeme.
Sie interact mit einem anderen.
Und es sieht aus, wie die Legislature ist, eine große Schöne.
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 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.
Und so, sie sind nicht ein Artifakt, der Struktur der Software oder wie ich strukturiere.
Sie sind Dinge, wenn ich nicht diese weiß, ich bin aus dem Business.
Ich will die Dependencies, die reflektiert werden.
Ein weiterer meiner Arbeit hat mit Dave Weiss.
Er war ein Student von Parnas, aber smarter als Parnas war.
Und er ist wirklich großartig in dem Domain Analysis.
Und so, was ein guter Produkt-Owner sollte, ist analysieren die Domain.
Und es ist das Knowledge, dass sie die Team kommunizieren.
Das ist business knowledge.
Ich bin, und ich bin in dieser Art, diese Art und Software, all die Zeit.
Ich bin, du hast die FAD-Sachen, wie extreme Programme.
Du bist Kent Beck.
Kent Beck sagt, okay, wie du ein Banken hast?
Er sagt, well, du benutzt eine Metapher.
So ein Banken ist ein, was du kannst, was du kannst, und du kannst, und kannst du kannst, und kannst du kannst, und kannst du kannst.
Das ist ein Calculator.
Bullshit!
Ich meine, Ihr balance ist nicht etwas, was sitting auf einem disk oder in einem memoryen, sondern es ein computation über eine audit trail.
Und die Hauptarchitektur von einem finanziellen system ist eine audit trail und eine Transaktion Log.
Und so, Sie haben diese ignorante Leute kommen mit einem Software Engineering Perspektive und sagen, oh mein Gott, es ist ein Calculator, die man die domain knowledge hat, die man die theory hat.
Und die Dependenci-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-Sie-S 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.
I mean, so I would totally agree that getting the domain right and getting the split of the domain right is essential for building software successfully.
Das geht ohne zu sagen, in meiner Meinung nach, oder sollte es ohne zu sagen.
Und wirklich, es geht nicht.
Und ich würde auch sagen, dass die Metapher in Extreme Programme ist sehr einfach.
Es ist nicht genug, um zu wirklich capture, was die Systeme sollte sein.
Aber was ich ein bisschen confused bin, ist, ich könnte jetzt sagen, okay, so hier ist mein System.
Ich bin building Modules, according zu dem die Domain, das meinträgt.
Ich würde das, was mein Domain meintelsen.
So, du hast gesagt, es ist ein Audit Log.
So, ich habe etwas, was ein Audit Log, etwas, was an das Domain related zu dem Domain.
Und dann habe ich die Dependenz zwischen den Modulen und ich habe Software Architecture.
Und ich würde sagen, dass du eine gute Software Architecture hast, weil du nicht mehr Dependenz ist.
Das ist eigentlich was du gesagt.
dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, dass das eine Art, die System, die System, die Test, die Test, die Reden, die Lichter, die Lichter, die Lichter, die ich, die ich, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art, die Art to be visible and manifest and to cost me a lot when I violate them.
As Factor 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 fan 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.
Er ist über die Bricks in der Wallen.
Und er wird über 45 Minuten sprechen über diese Brick in dieser Wall und wie man sollte es.
Und es ist wie, ich bin sorry, das ist nicht was zu kümmern uns in Software.
So, let's assume, ich bin, in der Banking-Probleme, wir haben eine gute Verständigung über die Domain.
So, du hast gesagt, dass ein Banking-Account ist eine Audit-Lock.
Und wir haben uns ein Zeit, um das Konzept zu arbeiten.
Und wir haben es herausgekommen.
Das sollte sich fundamental sein.
Bank Accounts sind ein Konzept, das hat sich überhört, ich weiß, 100 Jahre, wahrscheinlich seit den Jahren.
So es sollte sich etwas ziemlich stabilisieren.
Was du gesagt ist, in deinem Erfahrung, oder in deinem Recomendation, ist, was Dave, die ist, die Systeme ist, dann haben wir die Systeme gewonnen.
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 should be possible to figure out what a bank account is or whatever your domain is.
So I think the throwing it away.
Das ist das Problem, dass die Japaner sah in der Produktion, wo man nicht die domain expertise hat.
Ich glaube, dass ich die domain expertise habe.
Ich glaube, dass jeder banking system sieht wie jeder andere banking system.
Und es ist nur Capitalismus und das Pretenzett von competition.
Das ist ein guter Ding, weil es Leute zu versuchen, zu versuchen, Dinge zu versuchen, zu versuchen, Dinge in unterschiedlichem anderen zu versuchen.
Aber jeder muss sich inventieren.
The wheel, again, themselves.
They 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.
Und ich finde diese Partnerschaft in Japan und in general, ich finde sie in anderen industries.
In Software, wir haben es nur auf die Ebene von commodities.
So, die String Library, die Operating System und so weiter.
Es ist nicht auf die Ebene von Strategie Business Value.
Whereas in Engine, das ist Strategie Business Value.
Ich bin, Sie können eine License von SAP und es hat eine Ebene von Business Value, weil es dir sagt, wie es dir wie ein Unternehmen ist.
SAP ist...
All the processes are there.
I mean, it's not limited to SAP.
It's just ERP, CRM, and whatever, or the standard software system that we have in the business world.
They actually have some business value baked into them.
And probably the value proposition that they have these standardized business processes that you just have to adapt.
Ich habe never gedacht, dass das eigentlich vielleicht ein sehr guter Beispiel ist.
Und das ist eine gute Idee, dass ich mich über das Ganze habe.
So, da gibt es gut und da gibt es bad.
Die gute Idee ist, was du gesagt hast, ist, dass ein vieles da ist.
Die bad Idee ist, dass ich SAP nicht so gut verletze, ich habe das Ding nicht.
Ich habe das Ding aus und hire ein kleines Team von Special Wizards, die spezialisieren, in der in customisieren SAP für die purposesen meiner business.
Ich meine, no one geht in SAP und kommt aus live, unless du einen dieser Wissenschaftler.
Was interessant ist, dass es ein relativt kleines Team von Wissenschaftler, die in und tweak SAP, um es zu machen, um es zu meinem Tune zu machen.
Ich brauche nicht hundreds von Leuten.
So, da ist ein interessant, da ist ein interessantes Story da.
So, ich habe zu admit, dass...
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.
Das ist, in a way, was you just described.
It's sort of knowledge sharing about the domain, right?
Yes.
Because those 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...
Das ist ein sehr interessantes Beispiel.
Okay, great.
Das geht zurück zu den Diskussionen, dass die Standard Software eine der manchenweise zu vielleicht auch mehr Produktivität ist.
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.
Ich habe eine Architektur mit mir und mit mir gefocusingen, um mich zu bauen.
Meine Frau und ich, Sie haben, wir haben sechs, sechs, sechs Jahre alt.
Wir haben eine neue Haus hier.
Und sie hat die Architekt für Wochen zu bauen.
Sie waren nicht überwunden, um die Produktivität zu bauen.
Sie waren nicht überwunden, um die Dependencies zu bauen.
Das ist die Arbender's job.
Ich completely agree, aber wenn ich die Diskussion mit dem Thema, also mit AI, es scheint, dass es ein vieles Fokus in der Industrie auf die Produktivität, wie viel wir in der Zeit, wenn ich auf AI lookate, manchmal sogar die Lines-of-Code, die sind auch immer, die sind, die sind sehr viel Sinn.
Und es ist eigentlich ziemlich logischer, weil wenn du ein Werkstatt hast, die Frage ist, wie viel Geld du hast?
Aber es scheint mir zu mir, dass das nicht das die Majorität in unserer Industrie denkt.
So, hast du eine Explanation für das?
Oder vielleicht sogar eine Lösung?
So, da ist ein saw in der Industrie, das hat gesagt, dass es nicht mehr so viele Blame für IBM zu verhindern.
No one can ever blame a project manager who says, well, 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.
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, you know, 20 or 30 that show, you know, 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.
Yeah, 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.
Yeah, yeah, yeah.
As you said that it should be about business value and it should be about providing value to some customer.
Es ist nicht über die Generationen.
Ich habe das Wort, wie Software ist eine Lübliche und die Features sind eigentlich die Asset.
Ich denke, das ist sehr, sehr wichtig.
Aber ich war wundern, warum wir nicht das wissen.
Und wenn Sie eine Idee, wie wir mehr Menschen wissen können, das ist natürlich ein Fortschritt, weil wir darüber reden.
Aber vielleicht ist es mehr zu es, weil wir...
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.
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 leveled out.
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 Shuha 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.
mit all diesen pretendem engineeringen hacks, das wir callen architecture.
Set das als dein Ziel, stattdessen zu machen, als zu machen, über die Beziehung zu machen, oder zu einfachen, zu einfachen, und zu einfachen, noch eine andere Art von Abstraction.
Die Industrie ist voll von diesem.
Most der Design Pattern von der Gang der Four sind genau das.
Das ist einfach das.
Das ist einfach noch ein Level von 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, you know, 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.
mit der AI-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-Ai-A 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.
Immerhard knows event storming.
Come and see this.
You'll get some good tips.
You can't make people...
aber du kannst natürlich incentivieren sie zu tun.
Ja, danke.
Und auf einen guten Abend.
Danke.
Danke.
Bye.
Bye-bye.