At some point in the late sixties, the venerable Edsger Dijkstra put in place the basic tenets of what is now termed “software architecture”. The origins of the actual term are murky. The basic idea, however, is that when you’re creating software, design, or “architecture” is a discreet process that is done before implementation. Much like building a house, you would gather input from whoever you’re building the house for and then create a plan. Builders can then take the plan and implement it. Thus, the “plan” for a piece of software is called an “information architecture document” (or I.A. as the kids call it) and the person who writes it “a software architect”. Other than infuriating actual architects, I can think of few positive things this approach has yielded.
It seems like a valid approach on the surface, and it’s easy to get one’s head around. Houses are a complex system, a piece of software is a complex system. If you make a change during the planning phase, it’s cheap. If you make a change after the thing is built, it’s expensive. The simplicity of the concept probably explains why it’s used so extensively in teaching systems analysis to college students, and why it’s so pervasive in the business world. Architecture works for houses, why shouldn’t it work for software?
What am I getting at here? Software as architecture doesn’t work. It’s never worked, honestly and I see no reason that it will suddenly start working. Let’s not kid ourselves. Software gets built in spite of this way of thinking, not as a result of it. Think about it. If you’re a developer, how many software projects have you worked on that had extensive IA wherein the final product looked exactly like the IA documents? I can’t think of one. In most cases, the two weren’t even close. If you attempt to draw the housing analogy in this light, it would be like drawing up plans for a raised ranch and building a nuclear submarine.
(Note: Before you start preaching to me about Agile, save it. A system wherein “engineers do whatever they feel like doing today” and “the client can go suck it” is not something I can get behind. Commence angry comments about how I don’t understand Agile. *sigh*)
The problem with software architecture is that the core assumptions are fundamentally flawed. The first assumption is that software systems are like houses. They aren’t. Even the most complex building is made from commodity components. There’s framing lumber, steel, concrete, etc. These are materials waiting to be assembled into a product. Design and engineering of buildings is a well-defined process. Things like how much load a particular wall can support can be mathematically determined. Software, in contrast, is a series of problems waiting to be solved to create a coherent solution. Even if the problems are meticulously well defined, solving them is rarely an exercise in assembling off-the-shelf components. This is what makes estimating the cost of software projects like trying to nail jello to a wall. How can someone say how long it’s going to take them to figure something out? They haven’t figured it out yet!
Another flawed assumption of software architecture is that software is so hard to write that making changes once the development process is in motion (or after it’s complete) will be exponentially expensive compared to getting it right in the planning stages. There was probably a point in history where this was true, but let’s face it: most programming tasks aren’t as hard as to do as they used to be. I could (and plan to) devote an entire article to this fact alone, but for now I’ll just say that I’m getting very tired of software developers talking about how impossible things are. High school students are developing software systems that are often more effective than development teams at large corporations. Are they doing everything perfectly? Certainly not. Are they following industry best practices? Unlikely. Are they building systems in weeks that take large companies years? You’d better believe it.
The final and most obvious flawed assumption of software architecture is that a correctly and meticulously designed software system won’t need to be changed. I highly doubt this has ever happened. Changes can happen any time in the development process for a variety of reasons. You might show a client an early revision of something at which time they pick it apart and request a bunch of changes. The parameters of the problem might have changed while you were developing. There might be something in the IA docs that just doesn’t work in the real world. Whatever it is, a completed software project is a moving target. Stop whining about how “That wasn’t in the requirements document!” Things can and will change before the thing is done. Count on it.
Now that we’ve established the flaws of making analogies between software and architecture/construction, let’s consider another industry that can execute very large and complex projects on very short time lines and adapt continually right up until the very end: film and television.
A movie or a television show (let’s call it a “production”) starts with an idea, which then becomes a treatment. A treatment is a short document that explains the story that’s going to be told at a high level. Based on the treatment, a script is written. A script dictates what actors will say, what locations should look like, what props will be needed, etc. The production is then made, based on the script. While scripts are often very specific, they’re specific about the parts that matter, leaving much of the detail open to the director. Scripts are usually written by writers who don’t have any real idea how cameras work or how to set up lighting. That’s because a script is a goal. The production is the means to achieve that goal. Scripts are far from immutable, even once production starts. Writers are present through the whole process. If something isn’t working in production, the writer changes it and it’s re-shot. Once a production is shot, it goes into post-production, wherein it is edited and refined until it’s complete. Change is an intrinsic part of the film and television work-flow.
Why couldn’t a similar process be applied to software development? Couldn’t we start with a specific and concise but mutable plan for what to build and then adapt as needed until we get what we want? Instead of fearing change, which is inevitable anyway, why not integrate it into the very fabric of the process? It works for film and television, and I’m pretty sure they have much tighter deadlines and much bigger budgets than your garden variety software project.
So let’s consider the steps of creating software products as productions as opposed to houses.
The Five Steps of Software Production
#1 - The Idea
Define, in one sentence, what the final product will do. This should be extremely broad. This probably won’t change over the life-cycle of the project. This will serve as the litmus test for every decision made by every person involved. If something you’re working on isn’t to achieve the end set out at this stage, it shouldn’t get done. Set a deadline here.
#2 - Treatment
In five hundred to one thousand words, describe what the system will do in plain English. Avoid any engineering-speak or technical jargon. Show this to your client or stakeholder. Make sure they understand it and can explain it to you in their own words. Ask them to change it as needed. Agree on this document, as it will likely be the most important one you write.
#3 - The “Script”
This is the closest we’ll get to traditional information architecture. It should be the fewest number of words and diagrams to express the basic workings of the system in question. For web projects, I often use the design comps. This document is the basis, not the bible. Don’t spend inordinate amounts of time detailing it, it’s going to change wildly before you’re done.
#4 - Principal Production
This is where you write the code. The goal is to get the basic core functionality working in a way that you can demo it as fast as you possibly can. As soon as you’ve got something, show everyone involved. Keep everyone engaged as much as possible. Respond to change as deftly as you can. Everything you do should be considered in light of the deadline set in step one. If something can be done before the deadline, do it. If not, it waits until post production.
#5 - Post-Production
There are issues inherent in any software system that just won’t be exposed until you’ve got it in front of real people. Once your product is in its “beta” phase, have a way for users to provide feedback. Measure feedback carefully against the original idea. If you can make changes based on feedback that serve the original idea, make them. If they don’t, forget it. This will probably go on continually so long as the system is serving a purpose (note that I didn’t say “intended purpose” as actual and intended purposes for software are often different.) When the core idea changes, it’s time for a refit or an entirely new system, which should be considered a separate production.
So there’s my far-from-finished thoughts. I hope this inspires you to shift your thinking when it comes to planning and implementing software systems. I’m interested in getting feedback on these concepts, as it’s something I’d like to develop into a larger work, either a paper or a book. I look forward to your comments.
