Good software architecture works just like the human brain
How much time have you wasted just trying to understand someone else’s source code that needs changing? Veteran software architect Dr. Carola Lilienthal discusses why software architectures need to reflect the human mechanisms for learning and understanding.
JAXenter: You’ve often spoken at conferences about why good software architecture works like the human brain. How have you come to this conclusion?
Dr. Carola Lilienthal: What I try to explain in my talks is that the brain has been trained to work in complex situations, complex systems, over the past 10 thousand years of humans on earth. For example, we’ve had to work with complex family situations. If you go into old castles, you see paintings of cousins, sisters, family trees – so our brains developed mechanisms to work with these structures.
And that’s what I try to emphasise, that we can actually use these mechanisms, these cognitive techniques, by building the software according to the techniques that our brains like to use. The brain has one mechanism that’s called ‘chunking’ – this is something we do in our head. This means we are able to see things while abstracting from all the details, which lets us build a ‘chunk’. So look around, you see a table. You don’t see all the details and all the individual things it’s made of. You see a table.
So one feature of the brain is to build these chunks and even recode them into larger chunks. That’s what the brain does all the time, otherwise we couldn’t understand a sentence or anything. And we can only process about eight of these chunks in our brain at one time. If it’s overloaded, things get thrown out, something else is overwritten on top.
“A huge amount of time is spent just understanding code.”
So if your software is built in a way that supports ‘chunking’, developers can understand more of what they see in it, of what they read in the source code. I’m talking about huge systems where people have to make changes. A huge amount of time is spent just understanding code.
There might be a bug in the software, and you’ll need to find where to fix it. You go through the source code and need to understand all these lines of code, the connections between classes and everything, just to locate what it is that needs to be fixed. And of course you have to understand some part of the system to fix a bug as well. Bugs usually aren’t fixed in just one line, but a collection of different things that need to be changed.
So of the software is built in a way that supports chunking, you’ll be able to remember more of what you’re looking at, and you’ll find your way in the code much faster when you need to fix it.
So what can developers and architects do?
The main issue is, what you try to chunk together must be strongly related. It has to form something that is really meaningful, that’s the point. You can’t chunk things that don’t belong together in a meaningful way. And here comes the software development aspect. We have ideas like this already. We talk about modularity. We talk about single responsibility. We talk about building classes, modules, whatever, with one responsibility. We want to separate issues.
Things that don’t belong together, we want to put in different pieces of software. Because (at least this is what cognitive science tells us) if we do that, people are much faster at chunking these modular items if they belong together in a meaningful way.
So are we essentially talking about a more modular architecture?
Chunking does point directly towards modularity. But we should’t just create modules for the sake of it, but instead because they let us form something that really belongs together from a technical and a domain perspective. So to create a class with the name ‘manager’ that does printing, eventing and whatever else, is not a good idea. It has too many different aspects.
We also have a very strong capacity to work with something that’s called ‘schemata’. We’re usually very fast in areas where we already have these schemata in our brain that help us. My favourite example is what happens if I tell you my father and mother are both teachers. In your head, the teacher schemata will appear. You’ll have ideas of what this is, you will have an abstract idea of a teacher, you’ll have prototypes, you might even think of your own teachers when I tell you this, and realise “Oh, that’s why she’s talking so much.” Or “Oh my God, she must have had a terrible childhood.”
“We need patterns that are easy to understand.”
They’ve done tests in this area of schemata and discovered that if you have the right schemata in a certain area, then you’re much quicker in that area than people who don’t know have them. One example uses the chessboard. They showed a chessboard with an arrangement of pieces both to a chess pros and to people who don’t know chess. The people who understood chess were five times better at reproducing the arrangement of pieces – but only if it was a realistic positioning of pieces. If it was completely random, both groups had the same capacity.
And this is what we want in software systems. We want our people to be fast at fixing bugs, changing the system. And if they can easily get the schemata, they will be faster. And in software development, we have things like design patterns. We just need to make sure to use them in a way to help people to work with them. We need patters that are easy to understand. Essentially, we need to control the patterns of our software.
So the problem is then, I suppose, that patterns tend to change. Unlike a piece of architecture in a city, a software architecture evolves and changes over time. How do software architects maintain meaningful patterns then?
In my opinion, it’s means a lot of discussion to find new solutions that needs to be done with the team. I’m a big fan of this and I work in a democratic team that works on the architecture as well. Of course, in big organisations this starts to get difficult, because someone has to decide. In any case, I always want the patterns to evolve and to be discussed in a group.
What I don’t like is if everybody has the right to invent new patterns for the system. Because then you have new layers of patterns every year. Then if you need to change something, there’s more and more patterns you need to understand. So patterns need to be discussed in a team.
Would you say this goes for software architecture in general?
Well, one of the reasons that software architecture erodes and acquires technical debt is because someone doesn’t know about the architecture. They weren’t part of the discussion, or this aspect wasn’t explained to them why it’s done this way. I’ve seen this several times when consulting.
One architect had to hide with me in a different room to discuss his architecture. We looked at his source code and visualised it. And suddenly he said “Ok, now I understand. We can talk to our team about it all.” And this then enabled the team to see their architecture and discuss why it’s built this way. And it’s such an eye-opener for a team to be able to discuss these things.
And afterwards when I come back to the company, everybody has a good understanding and regularly talks about it, the problems were gone. So I firmly believe: everybody has to know.
Finally, what would you say is the biggest obstacle for a software architects?
The first and most obvious obstacle, I think, is the project manager. Project managers have a different goal. Their goal is ‘finish the project in time and on a budget.’
And this is not at all related to the architecture that has to live for a long time, to the system that has to be refactored and maintained. These two goals are often so far apart that they can come into conflict.