Software Architecture?Posted: November 15, 2011
Software Development is one of those activities that is associated with the concept of architecture. So we have software architects working on the software architecture for the project, application, system or whatever. But personally, I think software architecture is a misnomer, an oxymoron, an illusion, a desire or a lie, depending on who utters it in what context. In any case, I’m very much convinced the association between software and architecture is incorrect.
Let me try to explain my view point by starting with a detour to the sports world. If you take a look at sports, like Football for instance, you can see that each team has a goal they want to reach, ranging from winning the competition (whatever that may be) to not being relegated. Apart from the season, there always is the next match, for which coach tries to prepare the team, starting from a comparison of strengths and weaknesses of team and adversary.
Football has strategies. Some teams play kick and rush while others play possession football. Some teams care for the ball, while others like tough defense combined with razor sharp counters (for a notable example, click here). Football has tactics like trick plays (click for a fine example), that can really change the course of a game. Football has an element of luck : some things work out better than anticipated, while sometimes the ball just is against you.
Skill is involved too (a demonstration by Zlatan) and there are many players and coaches (trainers, managers) who have a vision on how the game should be played and who certainly know what they are doing and why they do it.
Now, allow me to ask the following question: Does a football match have architecture? I’m pretty sure your answer would be “of course not”. So then why would software have architecture?
Actually, what is architecture anyway? It stems from the Greek “ἀρχι τέκτων” which roughly translates to “master builder”. So architecture would refer both to what the master builder does (process) and to what the result of his efforts are (artefact). Somehow, somewhere role and semantics shifted a bit, and these days, the architect does not really build anymore, and architecture refers to the activity of designing a structure.
So if Architecture deals with the design(ing) of structure, then what is structure? The structure is that what bares the load. In the context of a building, it’s whole of beams, columns, frames, struts, and other structural members, together with it’s spatial configuration. It’s the thing that, once built, or constructed does not change anymore, because you would have to start over. If you start a search for structure in software, you will find that there is none, or at least, there should not be one.
When working on a software project/product, you have to make choices, and sometimes, you can even see a really good solution to the current set of requirements. The problem is that you know these requirements will change somewhere in the future, and that your ideal solution will be too costly to change. So you apply the “design for change” stratagem, and you deliberately choose to ignore the solution that does yield the best fit to the requirements, but you pick the one that will imply lower costs for the future change of direction.
Basically you’re trying to avoid the software from assuming a certain structure. You’re doing the opposite of architecture. What I’m trying to say is that I think the metaphor is wrong.
I think a better metaphor is to consider software development as a (real-time strategy) game played against the universe. This game involves strategy, tactics, and luck, but it does not involve architecture.
There certainly is a strategical aspect in software development. It just doesn’t get a lot of attention, and if it does,
it’s usually in an overly simplified sloganesque language like “Design for change” or “KISS!” or “Separation of concerns”. In fact, when strategy is considered to be a relevant concept in the context of software development, it is almost always seen in relation to the process part, and never to the coding part directly.
Some of the strategic choices that impact chance of success for a project/product a lot, like development ecosystem, programming paradigm, and programming language are hardly ever made at all. Yet, the choices made there are equally important.
For example, Ken Thompson made one of the most successful choices NOT to write, what would eventually become Unix, in assembly language. A lot of people said he was insane, and it would never be fast enough. He was not to be deterred.
One of the worst choices was made by a company (which I shall not name) I worked for in the past. We were building a commercial end-user application in Java for OSX.
The reasoning went something like this:
- Linux users will not pay for software, and Windows users are not willing neither, while Mac users have an open wallet.
- Java is an excellent choice for both client and server side development, and OSX is a good Java platform
Both arguments were defensible but, at the time, 90% of the end users were on windows, so if you target a community with a product that will reach only a percentage of them,
it better be a big community, and not a marginal one.
The Java choice was quite unfortunate, but at the time, they still believed Apple’s promise to make OS X the best Java platform on the planet. Later, it became painfully obvious that Apple changed its mind.
In retrospect, it should have been done in some .net language on Windows, but hindsight is 20/20.
Software development has tactics too. A famous anecdote from M. Abrash in Zen of Graphics Programming goes like this:
Years ago, I worked at a company that asked me to write blazingly fast line-drawing code for an AutoCAD driver. I implemented the basic Bresenham’s line-drawing algorithm; streamlined it as much as possible; special-cased horizontal, diagonal, and vertical lines; broke out separate, optimized routines for lines in each octant; and massively unrolled the loops. When I was done, I had line drawing down to a mere five or six instructions per pixel, and I handed the code over to the AutoCAD driver person, content in the knowledge that I had pushed the theoretical limits of the Bresenham’s algorithm on the 80×86 architecture, and that this was as fast as line drawing could get on a PC. That feeling lasted for about a week, until Dave Miller, who these days is a Windows display-driver whiz at Engenious Solutions, casually mentioned Bresenham’s faster run-length slice line-drawing algorithm.
I learned two important safety tips from my line-drawing experience
First, never, never, never think you’ve written the fastest possible code. Odds are, you haven’t. Run your code past another good programmer, and he or she will probably say, “But why don’t you do this?” and you’ll realize that you could indeed do that, and your code would then be faster. Or relax and come back to your code later, and you may well see another, faster approach. There are a million ways to implement code for any task, and you can almost always find a faster way if you need to.
Second, when performance matters, never have your code perform the same calculation more than once. This sounds obvious, but it’s astonishing how often it’s ignored.
(Btw, I have since discovered examples that contradict his second rule)
An improved algorithm for a standard problem can suddenly make a whole range of applications viable where they were once considered too expensive for current hardware.
Nihil sine Strategiam et fortuna omnibus vincit
It’s difficult to find examples of luck in software development as most people being assisted by it have the tendency of disguising it as a stroke of genius. There is nothing wrong with accidentally being in the right place at the right time, and then taking advantage of it. Anyway, in science, they often use the concept of serendipity to explain fortunate coincidences.
I should wrap up, as this is looking more and more like an essay instead of a blog post.
Don’t misunderstand this rant, I’m not saying you should not plan ahead or think hard before you actually start coding.
But I am warning you that if you start out to create a software architecture, you will probably end up having one. Or as the famous quote goes:
“There’s two kinds of unhappy people: those that didn’t get what they wanted, and those that got it!”.
We’re looking for new collegues, software architects can apply too.