Software Architecture

This was an interesting read to me because it managed to convey the ideas and the intuition behind the thing that it was explaining (software architecture) without saying a single word about how anyone is supposed to actually go and create ‘a software architecture’. It kind of makes sense, since the thing it is talking about is very abstract itself. “It should do this, and do that without too much of this, and with just the right amount of that, but always taking that into consideration.” But not a word on ‘you might want to use these diagrams’ or ‘use a text file’, ‘a mailing list’. Just ‘a document’.

What I understood from that is that the document defining software architecture can be a lot of things, because you can do software architecture in a lot of different levels. At the beginning that didn’t quite ‘click’ with me.

But if there’s a position from this reading that I can agree with is this: from a programmer's perspective, knowing about and having your design (or ‘architecture’) in hand is like a guiding light. Like a scuba diver’s lifeline, or the mission objectives in a video game. It keeps you on track. When you take on a project, defining that higher-level ‘solution’ is a problem that you should only solve once, and the solution you produce must be one you can adjust later but most importantly, it must be one you can trust later. Because later you’ll be concentrated solving the fun lower-level implementation details and you don’t want to be questioning why you were doing all this to begin with. No one has time for that, you already went through it. Having that clear ‘architecture’ in mind allows you to go ‘oh, this is why things are this way, this is what that is supposed to do, this is how I’ll make it happen’.

In my experience, I’ve received this guidance from lots of different places: from a well-defined project folder structure (that is initially empty), to an ugly-looking drawing-diagram that conveys just the key points of what the thing I’m working on has to do. This is why I think it makes sense for the author not to talk about the object representing the architecture as anything other than ‘document’.