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.


2008 Accomplishments

Created a modular and extensible Programming Framework (Outlet), to build video players, CMS and other applications. Outlet reduces the development time by encapsulating functionality into portable components. These components are reusable across different projects and businesses inside and outside NBCU.

Other benefits include:

  • Easy to adopt and implement
  • Maximize efficiency. Component only have to be written once
  • The framework boundaries allow writing software 50% faster
  • It is a unique proprietary NBCU Framework that integrates C++, Java, JavaScript and ActionScript
  • Facilitated an environment for easy collaboration between vendors (i.e. Pando, Industry Next, Extend Media, Yume and Widevine)

Architected and led the development of the new AS3 Online Video Player to benefit NBCU businesses. These businesses include:

  • USA Networks
  • SciFi
  • Bravo
  • Access Hollywood

Architected an unique advertising experience to serve all businesses at once. Direct benefits are:

  • Give all the site equal opportunities of monetization
  • Stability and confidence in the product
  • Easy to update and scale

Architected and managed the User Interface (UI) and Information Architecture (AI) of the NBC Direct 2.0 (Download Video Player). NBC Direct reduces the content delivery cost by 70-75% through usage of P2P technology. It Creates new monetization opportunities while video can be watch offline.

Managed the UI, IA and design of the NBCU Media Publisher, and also architected the entire front-end. This application presents the following enhancements:

  • Friendly Interface
  • Great stability
  • Simplified and responsive UI
  • Optimized workflow
  • Easy access to the data
  • Extensible via configuration files

Accomplished releasing the following products:

  • Hulu Distribution Video Player
  • User Generated Content Video Player
  • NBCU Media Publisher (closed Beta)
  • Embedded Player 4.0 and 4.1
  • SciFi Feature Player (Alpha)
  • USA Feature Player

UNFPA Presentation



Flash ActionScript Programming and Design.

These presentations group a set of slides, allowing users to access them from a list or through navigation button. The content shown includes videos (FLV), images, audio, animated bullets and text. All presented synchronized in times specified in easily customizable XML files.

NetMedia Consulting / Mar 2005