Skip to main content
Blog

Software architecture and the art of telling lies

By 23 januari 2017juli 4th, 2017No Comments

My job is about telling lies. A lot of them. Not the big, evil ones but the tiny white lies. You know, when your spouse asks how you are doing, and your answer is ‘fine!’. It’s not really a lie, it is a sort of summary that leaves out so many details that it is not exactly true any more. The ‘TL;DR’ version. But it is good enough or, at least, most of the time. And software architecture is a lot like that.

 

software architecture tool

Our weapon of choice

As I commonly joke with colleagues: “software architecture is about simplifying the real world down to some boxes and then making sure the developers feel guilty that reality isn’t that simple.” And I think that is the essence of the job of software architect: simplify stuff enough so everyone can understand it. And try to make sure that everyone sticks with that simple story. Figuring out what the nasty little details or exceptions to the rules are and what is actually the core story. My job is minimising the amount of lies we have to tell to each other when we talk about our software.

These days it seems that the whole of computer science falls into two categories: either something is trivial (and boring), or it is NP-complete and therefore impractical. Everything in between is where we need to do, with a dirty word, engineering. Making painful choices between two evils. And convincing ourselves (and everybody else) that we picked the lesser evil. We have to make decisions based on incomplete information: whether it is lack of specifications, lack of time or resources or, most commonly, lack of understanding how the system actually works. And we know that whichever direction we choose, the disadvantages of that direction will come back and haunt us in the form of bugs. 

At my alma mater we did a lot of mathematics. According to Popper, mathematics is not really science since it is not falsifiable. If you consider computer science as a part of mathematics it becomes a bit more clear: in computer science we don’t need to discover how the world works, we already have a perfect definition of that: a program. There’s nothing to falsify since there are no assumptions. The program explicitly and very rigorously tells you how it works, down to the point where even a computer can understand it. It is not a model since it is not a simplification. But programs are getting more and more complex. Stating that we have a perfect definition of reality might be true but is not very practical any more. The whole existence of APM shows us that we have no idea what our software is actually doing. With the rise of AI and deep learning we actually are sort of giving up. Pretending to be in full control when doing large architecture is a big lie.

Geek-and-poke: Enterprise architecture made easy

Geek-and-poke: Enterprise architecture made easy

 

Any software architecture is a model. A model is a simplification of reality. And as such it is not reality itself. We need models to explain what is happening. So we skip over some details, we tell some white lies and everyone is happy again. We try to capture the complex behaviour of a system with some boxes and arrows and lie to ourselves that we now understand how it works. 

The beauty of computer science is exactly because of this conflict: at one side is the pure beauty of mathematics and at the other the pragmatic harshness of engineering. A software architect tries to create models that encapsulate the essence of an architecture. Basically, we draw boxes on whiteboards for a living, and damn, it is a cool job.