Defensive Architecture

In the state of New York driving a motor vehicle is not a right, it’s a privilege. As a part of the process it is mandatory that future drivers take a 5 hours class about safety driving. In this class new drivers have to watch several movies and a state certified instructor will provide all sort of recommendations about defensive driving; from always use the seat belt to how to stop the car if a tire suddenly  blows up. Still, over 70% of the people involved in car accidents believe that their driving skills are above average.

In a different context, I would say that most of the web developers probably believe that their programming skills are about average, and yet accident happens. In web, when an DOM elements is not properly aligned, or the Flash application does not run, or even when we get a 404, nobody dies. Unlike driving. That’s why programming is not a privilege, it it a right that some people earn by taking a 32 or 40 hours course that will certify that they can write a button in HTML, change its size with CSS and use Javascript to alert ‘Hello World’; or some other people  buy one of those ‘… for dummies’ book and become an expert by themselves.

By the way, there is nothing wrong with what I just mentioned. I am a self-thought person myself; I learn Flash Actionscript by downloading every single tutorial hosted in back in 2000. But I have to say that it took me some time before I allowed people to call me a programmer. I guess I didn’t think that it was safe for people to have me driving since I did not have a license (AKA Degree in Computer Science). But hey, I was doing 3D scripts using trigonometry and didn’t even know why the word ‘function’ was reserved.

Back to driving, or at least the safety part, the reasoning behind that class is very simple. Even when a driver knows and respect all the rules, obeys the traffic signs, and stay away from drinking and driving, accidents can still happen. Weather conditions, road obstacles, imprudent pedestrians, other distracted drivers, or a damn deer crossing the road in the middle of the night; are all factors that can cause accidents even if you are a good driver. That’s why new drivers are requested to take a safety driving class and learn about other actions that will reduce the chances of getting involved in a car accident. These defensive actions are well instituted and in some ways follow common sense and decades of driving culture.

Unfortunately when it comes to web, things are not always that obvious. There are a lot of books on Design Patterns, Object Oriented Programming , tons of frameworks available in every programming language, literature on best programming practices, coding standards, and other subjects that will illustrate how to build reliable scalable software. But nobody gets penalized for not following the rules. it is true that we don’t have to be mechanics to drive a car, and it’s also true that in today’s world with very little knowledge and effort we can accomplish a lot (at list in the web development world); but still we are required to take that defensive safety class.

What motivated this post is the fact that I have not found a single source of information that clearly defines how to architect applications in a safe way. I am not talking about doing things by the book, I am talking about architecting applications that are compatible with changing realities; primarily business and financial realities. Between the moment when a need is identified and the moment when a solutions is architected, built and deliver there is a change of reality. Every developer that I know has his/her own way to create solutions that can survive to changes but I don’t think that everyone agrees on a particular way. I won’t attempt to get some consensus, but I will quickly outline some of the ideas that I consider part of my personal formula for defensive architecture.

If any of my friends or not-friends have recommendations about doing web/product architecture in a defensive way, please write your comment. I will be happy to summarize the recommendations. For now, and just to finish I am going to list a few of the things that I consider keys of defensive architecture:

  • Never design to just to meet requirements
    You should fulfill the requirements instead, and think about the future of you application.
  • Consider my ‘love is not for ever’ rule
    Even if we love the way we did something, at some moment we will change it.
  • If something is more that one then the max number is undetermined
    People ask for one thing, then a second thing, then a third thing. You build it once, hack it twice. Invest on a airbag, make things scalable from day one. It is better to have something scalable and not need it rather need it and not having it (I am sure someone will disagree).
  • Everything eventually changes
    Even when the business rules say things won’t change, in reality things always do, so be prepared.
  • Stick to good programing practices
    It always pays off (OOP, design patterns, UML, etc.). “If you need a class to do two things the you need two classes”.
  • Add some open source frameworks to you arsenal
    You don’t have to build everything yourself. In fact it is silly not to take advantage of some of the great things that are available for free.
  • Visualize as much as you can before writing the first line of code
    Use any kind of resources that will help you visualize what you are about to build (UI, UML, comp, sketches, whiteboard, paper prototype, class diagram, etc.).
  • Focus on what people need not what people want (those are two different things)
    The ‘need’ describes what the problem is, therefore you can think of many solutions; the ‘want’ restrict the solutions to want alternative only. Learn how to distinguish between the two.
  • Always break big things into smaller things
    It’s not only easier to solve smaller problem; it’s tactically important, other people can help you. The challenge is how to connect the pieces.
  • Solve structural problems first, before dealing with the formal aspects
    This is some kind of creed.
  • Even complex problems can be solved with  simple but strong ideas
    The execution will make everything complex again, so why not stating with something simple.


The Camel Architecture

Years ago, back in college, a teacher of mine defined “Camel Architecture” as a “horse designed by the collective”. It was kind of funny but my teacher was not joking. As students we had to do everything: sketches, design, drawings, model, and depending on how advanced we are in the career we also have to calculate structure, electrical installations, etc. In technology as well as traditional architecture a single individual may wear several hats. This condition is primarily determined by the size of the project or the size of the company. The smaller is the company or the project the more likely we will see one person taking care of everything.

In a large project or a large company responsibilities are often times split among several people: the team. When roles and responsibilities are properly defined, one person will take care of the horse’s head, another will deal with the legs, and other members will focus on other parts. Now, this is in the ideal world. In reality the larger the team or the company is, the bigger is the chance that the horse will look like a camel.

In a table full of professionals that have been tasked with designing a horse, the number one goal is to agree on what a horse is. There are two implicit goals here: the number one is to achieve agreement; and the second it to define the horse. When roles, responsibilities and areas of expertise are well delimited, it is easier to reach consensus in a group. The lack of this delimitation will make more difficult to focus on the subject instead of focusing on avoiding conflicts.

Architecture is a discipline in which complex ideas can always be expressed in simple words. It must be understood by everyone. The downside of this beautiful quality is that everyone who is not an architect might have an opinion in architecture matters. An architect might say: the concept of the building is going to be a horse. Everybody has an idea of what a horse looks like but when it comes to define ‘the specific horse’ we sometimes might see significant variations from one person to another.

If we were to design a building with the form of a horse, we may have the owner requesting the head to be smaller; structural engineer may demand the legs to be longer with big feet; the financial guy may remind us to add more room in the back to make more money; the long tail might be a liability issue if it breaks so if have to be shorten. Everyone will have a unique perspective of the same reality and as you can see little by little the collective could turn a horse into a camel through consensus.

Raul Sanchez (v.1)

Raul Sanchez First Website

SanRaul v.1

Web Design and Flash Programming

This site host my portfolio with a small selection of the projects that did between 1996 and 2000. During those years I was entirely dedicated to 3D modeling and architectural visualization (computer rendering, 3d animation and video editing).