Category: Software Architect

Real-world programming is not about solving the problem that someone gives to you. In the computer science classroom you must solve the binary-sort problem it‘s given to you. In the real world, the best architects don‘t solve hard problems they work around them. The skill is in drawing boundaries around diffuse and diverse software problems so that they are stable and self-contained.

An architect should be able to look at a whole mess of concepts and data and process and separate them into smaller pieces or “chunks”. The important thing about those problem chunks is that they are stable allowing them to be solved by a system chunk that is finite and stable in scope. The problem chunks should be:

• Internally cohesive: the chunk is conceptually unified, so all of the tasks, data, and features are related
• Well separated from other chunks: the chunks are conceptually normalized; there is little or no overlap between them

The person who is excessively good at doing this may not even know that they are doing it, just as a person with a good sense of direction knows where they are. It just seems to make sense to them to break up the tasks, data, and features in a way that provides a nice edge or interface to the system. I‘m not talking about the actual interfaces of an object-oriented language, but system boundaries.

For instance, a relational database management system has a very nice system boundary. It manages literally any type of data that can be serialized into a stream of bytes and it can organize, search and retrieve that data. Simple.

What is interesting is that if the problem is stable then when it is solved, it is solved permanently. In five/fifty years time you might want to slap a web/telepathic interface over it, but your core system won‘t need to change. The system is durable because the problem is durable.

Of course, the code needs to be pretty neat, but if the problem is neat the code can be neat as there are no special cases. And neat code is good because it is easy to test and easy to review, and that means that the implementation quality can be very high. As you don‘t have messy code you can concentrate on things that are outside the domain of user-visible features like using reliable messaging, distributed transactions, or driving up performance by using multithreading or even low level languages like assembly code; because the problem isn‘t changing you can concentrate on driving up the quality to the point where quality is a feature.

A stable problem allows you to create a system with a stable design; stable design allows you to concentrate on making an application that has very high quality.

I overheard some people deciding that they need more layers in their architecture. They were right, as it happens; but going about it a little backwards. They were attempting to create a framework that would contain the business logic. Rather than solving some specific problems they started with the idea that they want a framework that wraps the database up and produces objects. And it should use object-relational mapping. And messages. And web services. And it should do all sorts of cool stuff.

Unfortunately, since they didn’t exactly know what cool stuff it would do, they didn‘t know what to call it. So they held a little competition to suggest a name. And that is the point at which you must recognise that you have a problem: if you don’t know what a thing should be called, you cannot know what it is. If you don’t know what it is, you cannot sit down and write the code.

In this particular case, a quick browse throught the source control history revealed the depth of the problem. Of course, there were lots of empty interface “implementations”! And the really funny thing is that they had already changed the names three times with no actual code. When they started they called it ClientAPI — the “client” refers to the customers of the business, not client as in “client-server” — and the final version was called ClientBusinessObjects. Great name: vague, broad and misleading.

Of course, in the end, a name is just a pointer. Once everyone involved knows that the name is just a name and not a design metaphor then you can all move on. However, if you can’t agree on a name that is specific enough for you to know when it is wrong, then you might have some difficulty even getting started. Design is all about trying to fulfil intentions — e.g., fast, cheap, flexible — and names convey intentions.

If you can‘t name it, you can‘t write it. If you change the name 3 times, then you should stop until you know what you are trying to build.