Software Development Analogies
I've been planning to write a series of articles about architectural patterns and was just running over an introduction to them in my head. You know, like: 'What are architectural patterns and why did I feel the need to write them?'. Well, the reason I felt the need was that there simply weren't any. But 'hang on' I hear you say - what about the "Pattern Oriented Software Architecture" books? What about 'Patterns of Enterprise Application Architecture'? Sure; they're useful books - they make you think about the design problems you face every day when you're putting together enterprise applications, but notice I said 'design' there not 'architecture'? So what is 'architecture' exactly? Or more precisely, what is 'software architecture'?
I could go down this rat-hole, but that isn't the purpose of this article. I guess it will have to be the purpose of an article before I can describe my wonderful architectural patterns. I guess I might have to write an article about what patterns are too - you can never have too many of those right? But this reminded me of another issue I have with software engineering, and its this:
We just don't seem to have our own ideas about it. We borrow terms and concepts from every other field of endeavor. We struggle to impose order on a process that all too often seems to go off the rails. We do what every human being does when faced with this situation - we look for analogies that might help us control the chaos.
Look at the terms Software Engineering and Software Architecture. Look at how projects are managed - using techniques borrowed from hardware engineering or production lines. Look at the language we use to describe the artifacts we produce: Components, Service Bus, Plug-ins - we want to emulate other techniques proven to work in other environments (i.e. electronics).
The point is that we don't yet have our own vocabulary for much of what we do. We have some vague idea of what should be happening but as long as its vague we're going to have a hard time convincing anyone outside our field that we know what we're doing. In fact we have a hard time convincing anyone within our field too. For example I like to think of myself as a software architect but I can't really define what that is and everyone has their own idea and they never seem to really mesh. Even worse there is really no formalism that can be followed so no one knows ahead of time what they're going to get and I don't know what I'm going to deliver.
Whoops, I strayed down that rat-hole again and that, after all, is not the point of this article. The point is simply to say that I wish we could come up with some original ideas. Of course that never happens. Even when it seems to happen, if you dig deep enough you'll discover that it didn't. Einstein wouldn't have come up with his theories if he hadn't been embedded in the environment he was. Newton wouldn't. Isambard Kingdom Brunel wouldn't. Mendel wouldn't. Godel wouldn't. Closer to home: Turing wouldn't and Von-Neuman wouldn't. But we are all, consciously or sub-consciously, straining to come up with those ideas. That's why we jump at anything that seems to offer some glimmer of hope. That's why we have software fads like eXtreme Programming, Agile develoment, Object-oriented design (try and get somone to define that!), Service Oriented Architectures, CORBA, C++ etc. etc. (please don't try to tell me that they're not fads).
But please, lets stop with the analogies. If anything, that's why I like Agile Development - someone actually stood back, analyzed what was going on and proposed a solution to it rather than just saying something like: "hmm - farming faces this sort of problem - maybe we could borrow their ideas and terminology wholesale". The ideas behind Agile Development may or may not stand the test of time, but we could do with more of this sort of originality. So please, recognize that analogies can be useful when you're trying to explain something to someone unfamiliar with your field but if its your entire theoretical framework you're screwed.
Colophon
No article would be complete without some links. So here's some:
Carneqie Mellon: The only attempt I've seen at formalizing software architecture.
Steve Yegge's Blog: A hatchet job on agile development - and besides no article would be complete without a link to this guy.
Enterprise Application Architectures: Nice picture of a bridge on the cover of his book. It was part of the 'Big Dig' in Boston - a project reknown for being way over budget and suffering from several embarrasing engineering failures.
