Building a better horse

Martin Fowler wrote a post recently on the value of Design. Quite a good post, actually, in which he states that the productivity gain collected by doing "no design" is illusory for systems of sufficient complexity or size. 

I agree with the fundamental precept of the article, but I must disagree with one of the conclusions.  Let me explain by way of an anecdote.

The year was 1957.  It was late summer and the meeting room has become stifling hot, even with the air conditioning running.  IBM CEO Thomas Watson Jr had spent the day listening to an endless debate among engineers about how to cram more information onto drum-style disk drives and keep the data coherent.  They had a major show to prepare for in Europe, and the hardware wasn't quite right.  By 3pm, everyone was dying for a break, and the attendees decided to take 15 minutes to get some air. 

Mr. Watson was irritated.  He expected to spend a late night at the office and he was going to have to call home and explain to his family why the CEO had to work late.  As he waited for the elevator to take him to an upper floor, two engineers stood next to him, waiting for an elevator going in the opposite direction.  They were arguing (loudly) about the technical details of their work.

Mr. Watson's elevator arrived first, and he jumped at the chance to get away from the bickering engineers.  As he entered his elevator, he stopped, leaned back out, and said:

"If it were 1910, you would be the guys trying to figure out how to build a better horse and plow, instead of thinking about building a tractor!"

Moral: the problem we are solving may be moot if we are not considering the context in which we solve it. 

We live in an age of craftsmen.  Among the greatest craftsmen, the craft is very important.  Skill, quality, accuracy, precision, and beauty are all parts of the mix we call Software Development.  Admit it.  We are crafting, one at a time, an ornate and beautifully crafted solution to a unique business problem.  For some problems, this is justified.  For others, it simply is not.

In real life, when my toaster oven broke, I bought another one.  I made no attempt to fix it.  It was not worth my time. 

I'd venture a guess: well over 90% of our problems are not unique.  They are common.  Every business has nearly all of the same issues, and most are not competitive differentiators.  Yes, for all applications, strategic or not, we apply the same craft skills, even though the advantage we gain from craftsmanship only really apply to the unique strategic applications.  The rest do not need craft.  They need construction from prebuilt components.  I need a Home Depot where I can buy the hammer I need, not my own personal forge to make each hammer, one at a time.

We will never kill off complexity.  Applications that create competitive advantage may be complex.  We need to craft these systems carefully, leveraging prebuilt components and careful design.  The rest of the problems do not need craftsmanship.  They need to built out of completely disposable components that can be delivered so inexpensively that when it breaks, we discard it and put in another rather than repairing it.  Using craftsmanship to address these problems is focusing on the horse and plow when we should be using a tractor.

Martin eloquently argues that a solution that requires no design is, by definition, very simple, because the bar that you need to cross is fairly low before the complexity demands good design, I'd say that is true, but only because of our present immaturity.  Sure, we have to live in the here-and-now.  But if you really want to change the world, raise that bar.  Make it so that the needs of the business can be met with business specific, standard, interchangable components for 90% of all requirements.

Design is, and will always remain, the art of the intelligent and thoughtful few.  In the future, the majority of systems will be delivered with very little design at all... simply assembly.  The age of craftsmen must someday end.  The one who ends it, wins.

Comments

• Anonymous
  July 13, 2007
  "If it were 1910, you would be the guys trying to figure out how to build a better horse and plow, instead of thinking about building a tractor!" Sure: an internal combustion engine has proven to provide more horsepower than a horse and plow, both theoretically and in hindsight. But, if it's 1910, you've got to convince the CEO and CFO and CTO to risk a business built on top of horses and plows that everyone in management is comfortable working with, cut profits (perhaps to the point of having quarters in the red), put bonuses and raises for employees at risk (and therefore put employee morale at risk), and reduce dividends to shareholders. And that's just the risks of making the decision to go ahead. There are no assembly lines to manufacture the machines, no skilled workers to work the assembly lines, and skills for these workers have to be invented, along with new tools for these workers to use, and factories for these workers to work in. This is all new investment, in unproven technologies and techniques that have to be invented from nothing. But even if we get this far, and we can manufacture the engines, what fuels this new product? Horses only require ubiquitous and relatively-inexpensive food and water. The fuel for internal combustion engines requires oil drills, oil pumps, oil refineries, and ... oil! The business must now invest in the pursuit of oil and its refining and distribution and sales and taxation: well outside the domain of a business that simply manufactures plows designed for horses. And then, there's the tractor that has to be built around the engine. And then, customers have to be convinced to commit spending money to use the unfamiliar, unproven tractor instead of the familiar horse and plow that they've always used. And, given the investment, customers will be asked for far more money than a competitor's horse and plow would cost. Who, in management, would take these risks and losses seriously, especially when they come from someone who is not a manager, and obviously demonstrates no consideration of ROI? Now, compare this engineer's solution with another engineer's solution: there's a way to make the plow lighter, so the horse can do more work in the same amount of time, or can do more work by working longer before exhaustion, or the horse lives longer due to the reduced stress so that less horses have to be purchased by the customer to use the plow. If these two engineers argue their solutions, which solution is going to be more attractive to the CEO? Alternative solutions for managers to choose from are part of the value of engineers arguing solutions. Disagreement should not be anathema. Arguments are simply the bustle in the marketplace of ideas.

• Anonymous
  July 13, 2007
  @Donald, Please read about the history of the John Deere company. They did not invest in oil.  Engines were being built by their competition (Ford and International Harvester).  They bought the ability to build engines by buying a tractor company (they had been primarily a plow company before then).  Note the year: 1915. http://www.deere.com/en_US/compinfo/student/timeline_1900.html Companies change.  They must.  If you are not aware of the competitive pressures for your enterprise, or if you assume you have to invent everything yourself, you will miss opportunities.  There are always ways to reuse things.  John Deere benefited by being able to reuse the gasoline infrastructure that was already in place from Ford Motor Company's Model T (which had been selling well for a number of years). The engineer who builds a better horse drawn plow will have done a great job of solving the wrong problem.  That is what Martin wants us to do: build a lighter plow.  Perhaps that is the right short term solution, but it is not the long term solution. Notice that, in the anecdote, Mr. Watson did not stop the debate.  He simply asked them to expand their minds to include the actual business problem.  It is not to make a better plow.  It is to make money.

• Anonymous
  July 18, 2007
  The comment has been removed

• Anonymous
  July 18, 2007
  The comment has been removed

• Anonymous
  July 18, 2007
  The comment has been removed