More Expensive and Complicated Equals Better: Carseats and Software

So I finally got around to checking out the TED site; I've quickly become a fan. One of the first talks I watched was Steven Levitt's child carseats talk. Both the talk and the feedback comments on the TED site reminded me of things I see in software development. Here's the video if you haven't seen it.

Steven Levitt shows in his talk how 30 years of data on car crash fatalities imply that carseats do not outperform regular seatbelts for children ages 2 and up. Anyone who has a child or grandchildren will probably bristle at hearing that; as the father of a pre-schooler, it certainly gave me pause. We spent no small amount of time and decent chunk of money in selecting carseats for our child, thinking we had done our best to ensure our child's safety. For that matter, it would be illegal for us not to have done so. To see a decent-sized data sample suggesting my child would be better off in a seatbelt at her age is rather unsettling.

By the end of the talk, I took away these observations:

  • This great swath of an initiative was started by a very small yet vocal group of proponents whose assertions received little scrutiny.
  • A solution tailored to the specific constraints of a portion of the audience has been put forth as the de facto solution for the entire audience.
  • There is an ongoing assumption that the more complicated and costly solution must be superior to the simpler, existing solution.
  • Cursory evaluation of a data set without rigorous attention to mitigating factors can lead to wildly inaccurate conclusions.
  • The acceptability of a given solution is often tested against a narrow band of the overall criteria, and the solution is often optimized to pass that test.
  • The likelihood that people will continue to choose the more expensive and complicated solution despite any data is high.

So, software professionals, does any of that sound familiar? It reminds me of numerous initiatives over the years that have led us inexorably to the software productivity morass we have slogged through for years now. I suppose the most heinous case study in my own experience would be J2EE and the insistence that it was the solution that any reasonable business application would choose for a platform. (Before you .Net folks jump on that one, DCOM and later the .Net enterprise stack was much the same.) And who hasn't read a benchmark or white paper with seemingly incontrovertible data depicted in highly-polished graphics insisting that Product Y is the one solution to address them all?

I noticed that there were comments below the video on its page at the TED site, largely because the negative verbiage of the topmost comment jumped out at me. I took the time to read through them all (there were 36 at the time of this writing), and to my amusement, I saw parallels between them and how people react to questioning and examining our existing practices and means of developing software. See if any of these strike a chord:

  • The idea that what we're doing might be wrong unsettles some people, and their response is often ferocious and irrational defense of the status quo.
  • Those who have a financial stake in the current mode of operation are less likely to be open to scrutinizing it.
  • There will be some people whose primary objection to the scrutiny is that they didn't think of doing it first; these people will sometimes attack the person questioning things on the grounds that it's all a selfish, attention-mongering endeavor.
  • There are some people who will also be open to examining why and how we're doing things; whether they conclude the same thing or not, they are a welcome presence among the larger mass of those who ardently refuse to entertain the possibility of a need to change.

In recent years I've been greatly encouraged by the willingness of companies to question whether or not the heavyweight frameworks and technology stacks are what they should be using. Helping companies slough off high-ceremony processes in favor of right-sized process that focuses on delivering the right software in a timely manner has been some of the more rewarding work I've done the past several years. I think we have an encouraging number of people in the industry who are challenging the "more expensive and complicated always equals better" mantra.

For the brave individuals willing to put these questions to the community at large, I hope you find some comfort in knowing that the resistance and rejection you will encounter is a thing to be expected; you are not alone in that respect. Here's hoping we continue to be open to self-examination, no matter what emotional responses it might provoke or what fear of the future it may stir up within us.


Comments powered by Disqus