Outside the technology industry, engineers sometimes build multiple prototypes before selecting one particular design. Rather than finding the defects of one proposed design, discarding it, and moving on to the next idea, engineering teams that apply this approach, set-basedconcurrent design, save themselves a lot of time and headaches by running through as many options as possible simultaneously. As you might have guessed, this technique isn't cheap. You need to staff multiple design teams, and prototyping in many industries, such as automotive manufacturing, is always expensive. Nonetheless, by delaying the design decision for as long as possible, until the team has found the best among multiple ideas, development can take less time, with a greater probability of building a good product, than with sequential design.
So why don't we build software this way? For Microsoft, SAP, and other technology companies, prototyping is orders of magnitude cheaper than it is for Toyota and General Motors. Executives at tech companies would love to reduce the unpredictability of development schedules, often thrown off-track by unexpected design issues. So why hasn't set-based design caught fire in the technology industry?
That question has been plaguing me since hearing an excellent presentation by Jean Tabaka and Bill Wake on this topic at Agile 2009. I'm not sure of the answer ("More research required," says the analyst), but I'd be amazed if it didn't include two factors: (1) the nature of the product being developed; and (2) the unspoken assumptions of the tech industry.
If you're still baffled, flummoxed, or concerned about Facebook's now-infamous privacy policies, here's a handy chart from The New York Times. (Thanks, Madiha, for the pointer.) While the diagram retains a neutral tone, it's hard to read the phrase 50 settings with over 170 options without having a "What the hell?!?" moment.
In defense of Facebook, they're no worse than many technology companies that devise confusing UIs, full of knobs and dials that users don't understand or use. These companies are still to blame for creating the circumstances in which a confusing UI is hard to avoid, so they're not completely blameless.
An apology to future generations
Here's where we venture into the idiosyncratic sub-culture of the tech industry, which is hard to understand if you've never been part of it. In spite of having big development budgets, a staff of seasoned professionals, and months to build a useful product, tech companies repeatedly build software that begs the question, "Daddy, why is your product so hard to use?" (Even weirder: usability is often inversely proportional to the price.)