Tuesday, May 22, 2007
  The Not So Big Software Design

(This essay appears in the e-book What I've Learned From Failure: A quarter-century of experience shipping software, distilled into fixnum bittersweet essays)

A little less than a decade ago, Sarah Susanka wrote a very provocative book, The Not So Big House. I found out about it one evening while watching PBS. I switched to Channel 17, and there was an interview with her in progress. My partner and I were enthralled. We had been struggling to purchase a new home from “tract” or “subdivision” builders, and we simply couldn’t find anything that spoke to us. In a few short moments, Sarah articulated exactly why we were so frustrated by the builders.

Sarah spoke about a culture of building homes to impress. Of cookie-cutter McMansions, where everything was big, but nothing was warm and inviting. I can give you a very practical example of this syndrome: drive through any subdivision these days. Measure the space between the houses. It’s pitifully small! The reason is that the builders are building the largest homes the possibly can on each lot.

The Not So Big House: A Blueprint for the Way We Really Live emphasizes personalization: building a home that fits the way its owners actually live, not just a cookie-cutter idea of what life might be like or what features will be most impressive when company comes to visit.

The design conflict described in the book—the tension between designing for actual use vs. designing for size and visual impact—is uncannily similar to the tension between Agile (build what you actually use and need) and Buzzwords (build everything you might need using the most impressive technology stack available).

That means that very little light can get into the sides of the houses, and you see this when you look at the floor plans: everything is organized around large picture windows in the front and rear of the house. And no wonder: there is nothing to see to either side except the brick or siding of your neighbour’s house just a few feet away.

Sarah’s solution to the problems of poorly designed homes is to take a given budget, and instead of buying the largest home for that price, purchase a smaller home but invest in features and details that customize the home for your needs.

Applying this “not so big” thinking to the problem of houses squeezed together in a subdivision, you can try to place a smaller home on the lot and invest the construction savings in windows on three sides instead of having nearly all the windows on just the front and the back.

Everything in Sarah’s philosophy is driven by the owners’ actual lifestyle, not some imagined lifestyle that never comes to pass. So… unless you are a competitive dancer, Sarah is not going to design an impressive ballroom for your home. On a more practical note, she spends quite a bit of time discussing the merits of doing away with the formal dining room.

Very few people want to have company over for dinner in their kitchen, so Sarah often designs an eating area separated from the kitchen by sliding doors. You have an eat-in for everyday dining and a formal spot when you need to throw a dinner party.

This kind of thing is not free: sliding doors are expensive, and that’s why very few “tract” homes have them, even very expensive tract homes. But if you want a home that works, you make the choice to have fewer square feet but make those square feet work for you every day.


The problem with tract houses can be summed up in a phrase: the builders are selling you lemons. I hope Bruce Schneier forgives me quoting wholesale from his excellent article about security problems:

In 1970, American economist George Akerlof wrote a paper called “The Market for Lemons,” which established asymmetrical information theory. He eventually won a Nobel Prize for his work, which looks at markets where the seller knows a lot more about the product than the buyer.

Akerlof illustrated his ideas with a used car market. A used car market includes both good cars and lousy ones (lemons). The seller knows which is which, but the buyer can’t tell the difference — at least until he’s made his purchase. I’ll spare you the math, but what ends up happening is that the buyer bases his purchase price on the value of a used car of average quality.

This means that the best cars don’t get sold; their prices are too high. Which means that the owners of these best cars don’t put their cars on the market. And then this starts spiraling. The removal of the good cars from the market reduces the average price buyers are willing to pay, and then the very good cars no longer sell, and disappear from the market. And then the good cars, and so on until only the lemons are left.

In a market where the seller has more information about the product than the buyer, bad products can drive the good ones out of the market.

Now don’t think about the house builders as bad people trying to sell you a bad house.

In the case of new homes, the bottom line is that if most buyers of homes cannot tell the difference between a home that will suit their lifestyle and one that will not, the builder has very little choice but to offer homes that offer the superficial features (like gross square footage) that will sway people into buying.

The entire problem is centered around the fact that the average home buyer is unable to tell the difference between a good house and a bad house, so they settle for superficial distinctions.

Building Better, Not Buzzwordier

Does this sound familiar? There are two obvious blog posts here, one about the fact that the average employer cannot tell the difference between good programmers and bad. The other about the average buyer of custom software. Since someone has already noted the similarity between used cars and programmers, let’s look at the similarity between houses and custom software projects.

I recently had a chance to review an architecture design for a custom software project. The designer was given a telephone book sized specification written by the client and asked to put together a high-level architecture plan.

Now right away, I want to say this is a tough spot to be in: it’s all well and good to talk about customizing things for clients, but you really need to talk to them if you want a shot at doing a good job. Whether you are a proponent of Agile or of BDUF, I think you will agree that no amount of documentation can replace communication, ever.

Any ways, I saw right way that the document was… What is the phrase?… Oh yes, as Richard Feynman would say, it was no damn good. It was a lemon.

It is very poor form to criticize this person’s work after establishing that they had very little chance of doing well. So this is my disclaimer: I am writing to talk about why these circumstances conspire to produce a lemon of an architecture plan. Got it? Good person, bad circumstances.

So what was wrong with the design? Quite simply, there was no client in it.

There was a technology stack, there were buzzwords, there was a very popular programming language, there even were some quasi-open source components. Lots to like, and difficult to criticize. Think about how such a conversation might go between two lemon sellers: “Why are you specifying Java, C# is the best language!” Or perhaps, “BizTalk?!?! No way, you want open standards, not lock-in!”

But there was no client in it. Tract houses are designed for the features that all inexperienced clients want to buy, making owners and tract houses interchangeable.1

And this design articulated the features that inexperienced clients (and inexperienced software designers) like to think about. These kinds of designs and clients are equally interchangeable.

Where is the client?

What I saw was a design with such broad strokes (“Database,” “ORM,” “Workflow,” “Templates”) that it could have been presented to hundreds of different clients without change. Now obviously, hundreds of clients need databases and what-not. So the design wasn’t wrong in the sense that none of the decisions it articulated were bad decisions.

But let’s stop for a moment and compare that architecture design to a home design. Imagine you hire an architect. They put together a preliminary design, a kind of sketch, for your consideration. They call you into their office for a presentation. The lights are lowered and the presentation begins.

The Consulting Engineer speaks. “Concrete foundation!” She says. Next slide. “Wood frame.” Next slide. “Brick exterior.” You are getting the same treatment as the clients looking at a design that goes into detail about the technology stack (“Java,” “Oracle,” “Hibernate,” “BizTalk”).

Or maybe the Consulting Engineer sits down and the Junior Architect takes over “Four bedrooms. Maybe five.” Next slide. “En suite bathroom.” Next slide. These things are all decisions that must be made, but they have little or no connection to the client’s needs.

Isn't it obvious that a well-designed home with vinyl siding is a better choice than a poorly designed home clad in brick? But in the absence of better information, clients are forced to pick the brick over siding instead of choosing whether to have a formal dining room or whether to separate the eat-in from the kitchen with sliding doors.

And obviously two parents and three children want at least four bedrooms. But there is no talk of whether the master bedroom is on the main floor, or whether the architect has chosen to place the play room adjacent to the children’s bedrooms upstairs where the children can play without disturbing the adults or whether to place it downstairs where it can be seen from the kitchen.

It’s easy to see that the exterior of the house and the number of bedrooms are superficialities: To get at the important details, you have to ask a simple question: How is this different than what every other client is getting?

The really important architectural decisions are the ones that address how each client is unique, not what all clients have in common.

Better Software Architecture

Designing software is not easy. And truthfully, our environment makes it difficult, because our clients are not knowledgeable enough to distinguish the not-so-big applications (“Domain-specific languages,” “Agile development”) from the McMansion applications (“Industry-standard platform!” “Detailed Specifications!!”)

In the context of software developed for clients, good software architecture is, at its heart, architecture that is specific, not general. It isn’t all high-level abstractions that could apply to any client, it’s specific choices that address specific problems for that specific client.

It is easy to say that the cure for the general architecture is to add detail. If the lemon design requires five slides, flesh the design out into fifteen slides. If that isn’t specific enough, triple the length again and go to forty-five slides.

This would be the equivalent of taking the builder’s floor plan of a McMansion and filling in the exact dimensions. Or perhaps selecting the kitchen finishes and whether the shower fixture will be pressure-balanced or not.

Adding detail makes a design more specific, but it only makes it specific for a client if the choices expressed address the most important needs of the client. Naturally every new home buyer has a preference with respect to kitchen cabinetry. But does expressing that decision really reflect a deep understanding of the client’s lifestyle?

When you look at a high-level design for a client, it should be obvious at a glance that the design addresses specific needs. Someone who doesn’t know the client may need an explanation—if you looked at a home design with the master bedroom on the ground floor, would you know instantly that the clients have teen-aged children?—but if you know a little something about the client, you ought to be able to literally see the client in the design.

This should be true at each level of detail. It should never be necessary to drill down into the details to understand how the design solves the client’s specific problems. If you are looking at a five-slide high-level design, it should convey the one or two most important ways the software will solve the client’s most important and pervasive needs.

When you drill down to detail requiring forty-five slides, you should see solutions to problems that are a ninth as important as the solutions evident in the five-slide presentation.

Like Sarah’s approach, this type of design has a cost. When you only have five slides, using one slide to address a client’s specific problem means foregoing a slide full of buzzwords that impress the less-knowledgeable client.

I wish I could tell you that this will outshine the McMansion presentation from the big consulting firm full of buzzwords and no attention to the client. But it will not: most clients will buy the idea that their needs are not-so-unique, and if what they need doesn’t fit the architecture, they must change to adopt “best practices.”

But for the serious practitioner, good design is more important than technology stacks and buzzwords. More important than size and impressiveness. It may be “not so big.”

But it is better.

  1. In all my looking at tract houses, I saw just two departures from the norm: one builder offered a two storey model with a master bedroom on the ground floor so that when they children moved out and the owners aged they wouldn’t need to go upstairs (bungalows solve that problem as well, but you need a much larger lot). Another style, “New Urbanism,” put garages back behind the house where they belong. But 99% of them were just variations on the same theme.



Comments on “The Not So Big Software Design:
This reminds me of Christopher Alexander's work, Richard Gabriel's writings on the matter and how it got picked up by the design patterns people.
Your analogy is extremely compelling, but you don't provide any concrete examples of how a carefully tailored software architecture provides a uniquely better solution.

I have always thought of floorplan-level customizations as being equivalent to providing carefully-tailored forms and database schemas, but this surely isn't what you mean by architecture.

Could you elaborate on when and how it is important to provide architecture-level customizations? I have a suspicion that you have an important point here, and that I'm missing it.
you don't provide any concrete examples of how a carefully tailored software architecture provides a uniquely better solution.

Thank you for pointing this out. I did wrestle with whether to give several software design examples, ideally in parallel with the home design examples.

I felt I might be venturing into Straw Man territory.

It's easy to quote a specific client's problems and talk about the importance of tailoring a design to them.

However, the more important issue here was not whether a program ended up being customized for a client but rather when this occurred.

I am arguing for customizing very early. In the case of "McMansion Software," the argument is usually that it is powerful enough to accommodate the client's needs: it is table driven, you need only wire your actions up with XML files, yadda yadda.

All that kind of talk just defers the complexity of designing for the client until later in the process.

And in fact, that is partially a good thing: the later you can defer unimportant decisions, the better.

But for the big, important issues, hand waving them until later means deferring them until it is expensive and difficult to accommodate the client's needs.

And thus, they are sometimes ignored.

A specific example? Sure. One of the world's busiest (as measured in transactions or dollars per second) web commerce sites is not-so-big.

We could talk about scaling and reliability, but this is like talking about the fact that they build with steel where houses are wood and brick.

More interestingly, they have many little customizations, as you wuld expect. So does Amazon!

One is a little scheme where they can randomly show different versions of every page to different customers.

They use this to test new layouts and see which ones generate the most sales. Every once in a while some genius decides that a whizzy flash thingie would increase sales.

They can test that on one out of every hundred or one out of every thousand customers and once again quietly kill the idea when the numbers show that customers leave those pages without ordering anything.
I love all of the stuff about lemon developers.

I actually like the big house on a little lot thing. Right now I live in a town house, which is basically the same thing. I just look at the small space between houses as making them townhouses with some additional noise buffering. Where I live, opposition to building large houses on old lots that contain little houses that weren't built for the ages is causing suburban sprawl, by forcing people out further from the center to build the houses they want. The McMansion label being applied to any rebuild is hurting the earth.

What I despair of is the lack of change in architectural style amongst the models. Why not have some truly modern and postmodern design elements in these homes, instead of "colonial" style, or some such nonsense?

The whole concept of houses designed to focus on either home offices or media rooms or big kitchens sounds good. The problem being that people think about resale, and this makes them want it all. It might not make sense, but they don't want to close out any possible buyers. I often wonder if it wouldn't be better to truly excite a smaller set of buyers, since only one person buys the house from you...
I think I'm with you now, and after thinking about your comment for a while, I'm convinced there's a lot of wisdom in what you're saying.

I'm used to primarily designing a generalized architecture that is inherently customizable in specific ways. But this is more like decorating a room to one's tastes.

I like the idea you raise that a software architecture should be designed or extended with specific affordances for the needs of clients.

Rather than wedging all client problems into the things we can already customize, producing new components to solve problems that don't match up with the base architecture seems like a better solution, and one that I hadn't really been thinking about.

Thanks for the good idea.
With respect to building around generic frameworks and components: this can be orthogonal to the issue of "not-so-bigness." After all, building software in a general-purpose language is an exercise in working with a generic framework.

That being said, the question becomes how do you intend to customize the framework for the client? What are the most important ways in which what you build with this framework for the client will be different than what you build with the exact same framework for a different client?

I'm not arguing against building with concrete, wood, and brick. I'm just saying that the choice of technologies is not a complete design and it's not a good way to distinguish good designs from bad.

p.s. Although I blog about Ruby and Lisp and other good technologies, I would be dismayed if a client selected me for a project solely on the basis of a promise to do the development in Ruby. My argument is that Ruby affords me the ability to design and build client-specific software, and the reason for selecting me is what I can do with Ruby, not Ruby itself.
I understood the part about how the choice of technologies is largely irrelevant to meeting client needs immediately. Honestly, I don't pay much attention to choice-of-technology issues these days: for better or worse, our framework is in .Net. This means that we have latitude in certain areas (we can build new features in F# or IronPython instead of C# if we want), and virtually none in others (we're fully committed to a MS technology stack, and if someone is determined to have a solution that uses J2EE, Ruby on Rails, or Linux, that's the end of the conversation).

In general, we always tailor our solutions to the client. We have a baseline of functionality, and then the ability to drastically customize the end result. But this is constrained by our framework, and it's more on the level of decorating.

What we typically haven't done much of until now is customizing the architecture on a per-client basis, which is what you've been talking about. For us, that means building new components, but that's incidental -- given the framework we already have, new components are simply what it means for us to customize the architecture. With a different set of technology choices this could be accomplished in completely different ways.

I believe we are in violent agreement. :-)
A lot of the examples in Freakonomics boil down to the lemon phenomenon.

A couple of random thoughts:

(1) While it is ideal to build the application specifically for the client (including down the architecture), it might not make the most money for the larger consulting firms. For example, if they sell you on their architecture, without considering your business, they get to build their architecture for you. That's X man hours worth of work. Then, you get into testing, and the client suddenly wants a whole bunch of changes (to match their business). That leads to Y man hours more in change requests.

Following your suggestion, it would take Z (where Z < X + Y) because the initial hours expended in X would be replaced by designing for the customer (what you're doing in Y). A large consulting company knows this is going to happen. They know that there are going to be changes. They want to capture as much of those changes in change requests and billable hours as they can. It produces a situation where it pays more to do the wrong thing. Only someone who has spent a great deal of time working on software projects (by definition, not the client in this situation) can possibly tell the difference. Is it any wonder that large projects backed by deep-pocketed clients run long?

(2) It seems that the most powerful thing you can do to help a client's architecture is to remove the things that are unimportant to them. You save time on implementing those things and you save the customer money (assuming, of course, you're not operating in a situation like that described in #1). Removal of architecture is more productive than building it and then having nobody use it.

(3) The way to combat "lemon programmers" syndrome (where cheaper, lesser programmers get the job) is references. Independent 3rd parties are what is needed, as suggested in the article. I personally think it is part of my job to educate my customer on what they should expect from their programmers / contractors. Conversely, if you are a contractor that is just starting out, your #1 priority should be to establish some sort of 3rd party ranking system or references.

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /