Sunday, July 10, 2011

Style and substance

Ford Shelby Cobra GT500 Show Car

There are people who, when asked what car they would like to have, say "Red, with a sunroof and leather seats". A car is a powerful machine that exists to move people and/or things from one location to another, handle high speeds, protect its content from strong hits, and last a significant amount of time.   Leather seats are cool, but are not exactly high on my list of important characteristics of a car.

Leather seats are not unimportant.  They are one of the first things that a person notices about a car, and have a big impact on the driver's and passengers' experience.   However, car owner's experience is more than just driving and riding in that car: most car owners also have to survive an accident or a dozen while in the car, handle service and repairs for the car, and occasionally drive in adverse conditions where good handling becomes extremely important. 

If a car was a piece of software, the leather seats would be a feature.  Engine, handling and protection for the passengers provided by the strong body of the car would all be parts of the architecture.   Many people, when thinking about software, tend to consider its features, and nothing else.   When these people are product owners or project managers, the product features get a lot of thought and resources, while architecture evolves like a weed, with little care and hardly any testing.

Let me continue with the car analogy: an automobile can have the best-quality leather in the world on its seats and also be a complete lemon.  The wonderful seats won't make the car run, be safe or reliable. Same goes for software projects: great features do not guarantee usefulness, user satisfaction, or return on investment.  While features of an application make or break users' experience, the software, like a car, must also work, handle its load gracefully, and protect its owners and users from failures.   And that takes effort: time, resources, and careful thought about software architecture.



  1. Depending on who the car is for, the engine, transmission, handling, safety features (especially for crunchy parents), and even the tires might instead be considered features.

    Driving a sports car with an automatic transmission lacks something.

    I think the biggest hurdle to cross in software development is adoption. People don't want things jammed down their throats. In software, you have to consider the needs and desires of both the customer and the end user. There are countless examples of the customer wanting things that are bad for the end user. The converse is true as well.

    I still think the hardest part of software development has nothing at all to do with writing code and everything to do with people. Software people are counselors, advocates, referees, wranglers, and a whole host of other roles.

    Having well implemented code is important, poor architecture resulting from poor judgment or a lack of planning can and do cost companies users and business, but if your experience sucks, it won't matter how pretty your code is.

  2. Robert,
    thank you for your comment.

    Architecture has little to do with pretty code, and everything to do with "-ilities" - reliability, scalability, testability. What's considered "pretty code" helps to avoid bugs, to evolve features, to maintain the system, but ultimately it's means to an end, not the goal.