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.


Leave a Reply