Why programmers need to smell their software systems
If your software system is slow and struggles to ‘evolve’, there’s a good chance your team is only working one-dimensionally, says Gernot Starke, a leading expert in software architecture behaviour.
Let’s assume you’ve been a been a bad developer and you’ve neglected to take keep your code tidy. Then there’s a good chance your manager will call a guy like Gernot Starke, a German software architecture consultant who specialises in finding our where systems are going wrong. We spoke to him at the Software Architecture Summit in Berlin.
JAXenter: So Gernot, you’re a bit of a celebrity in Germany’s Software Architecture scene, as the author of Germany’s definitive guide to the dos and don’ts of software architecture. Perhaps you can first tell us what are the most important rules that software architects forget?
Gernot Starke: Haha, you’re sure you mean me? I think in many disciplines we have common agreements on basic knowledge and good practices and behaviour. And we tend to forget them in the rush of day-to-day business, the pressure for quick results, bosses calling for urgent repair. We then tend to put aside good practices and do a quick fix. We do that in all kinds of areas, processes, architecture, structure, code practices and so on. And when I visit clients that they know about the good practices in all these areas, and they know what issues they have there. But they put them aside for what they call ‘good reasons’. (even if they cannot explain the ‘good reasons’ afterwards).
It’s like brushing your teeth. From time to time you forget about it, it’s ok. But don’t neglect it as a rule or as a regular practice. Every kid knows that. But in software architecture, we don’t brush our teeth anymore. We just go to bed!
“In software architecture, we don’t brush our teeth anymore”
That’s one thing. another thing is the opposite: the quest for perfection. We failed last time, or at least we failed a little. And this time we’ll try to do it better. We use more and better technologies, we try to get better experts on board, we try to do better documentation, we try a better build system, try to be better in every aspect. But we forget that changing something also means risk. So we sometimes ignore the risks. Perfection is the enemy of the good. If you try to be perfect, you won’t find the correct exit point, you’ll still continue to optimise something that’s probably not worth optimising.
That’s the other end. And management tends to pinpoint this perfectionism and punish the responsible people and overreact at the other end and throw away all the great ideas and come up with a quick solution again. And then you’re back to square one.
I regularly talk to architects that maintain huge systems and build new components for them. They tell me about constant switches between being in the “fix mood” (we need to fix this problem urgently because something is standing still and waiting for repair) and being more relaxed and thinking about throwing it all away and starting from scratch. Both are not adequate, but this adequacy is not a metric. You can’t put an algorithm on it and execute it every day. The typical housewife has a clear concept of how to organise a household. Sometimes I think we lose this common sense. If you remind most developers of their common sense, they sometimes step back and think “Oh yes, how could I do that!?”
And that’s I try to give people as a tool – give yourself a reminder to check your common sense, to give yourself feedback.
So at the Software Architecture Summit you were speaking about typical problems in software architecture…
Yes, and how to find them.
So how do you find them?
Well, I’ve been thinking about an analogy for this. Imagine your fiancé comes to visit you at home and you want to make a great dinner. You prepare everything, buy fancy ingredients and put together all the ingredients. But imagine the only thing you were to test was the temperature. You don’t taste anything, you don’t check the texture, smell the food. You just check the temperature. Nobody would do that – it’s highly risky. You could do it with toast, just put it in the toaster, no need to try anything else.
But with software we have so many dimensions where we can introduce errors, problems, risks to our systems because they’re so immensely complex. We can mess up the data, we can mess up cross-cutting concerns. And usually people only look at their own source code. They only use one dimension to find issues. And then they try to fix these issues, you make the soup a little hotter, but it still doesn’t taste good. You might have the right temperature, you might have the right code metric, but you’re still wondering why the final result is so bad. A good cook will tell you, you have to smell a dish. It’s another dimension. In software, the temperature shouldn’t be the only thing you look out for.
You need to look at the processes of how you create software. If your processes don’t fit the problem or don’t fit the team structure, it’s bad. You need look out for your technical infrastructure. If your code is right, but your infrastructure isn’t, the code won’t run quickly enough and you’ll have problems.
You can often be heard speaking about the ‘evolutionary improvement’ of software – what do you mean by that?
We have many systems that run and are maintained over ten or more years. That’s a very long period of time. And you invest heavily in these systems every year, so these investments add up to a very, very large amount of money. So we need to minimise the amount we need to invest to keep the system up and running. And we’re talking big money here – not thousands, but hundreds of thousands and millions. So the easier it gets to maintain a system, the cheaper it gets. So it’s a cost thing, or a value thing.
“The easier it gets to maintain a system, the cheaper it gets.”
By ‘evolutionary improvement’ I mean, the usual situation is that it gets messier every day. Imagine you never clean up at home, you don’t have a dishwasher, clean the windows, dust the home. We call those people ‘messies’. No one wants to live in that house. But many software systems look like the home of a messie. It’s no fun working there and when you lose highly skilled people, adding new features becomes really nasty and you’ll get slower over time. And then management puts more pressure on because you didn’t make your deadline last time and you’re not going to this time. By evolution I mean, we want to avoid that. We want to have fun at work and keep our managers happy.