The UX of Wagonwheel Projects

There is an old story I tell to describe a common engineering project that goes wrong.

The Setup

A customer wanted us to build a content management system for them.  They insisted we use Linux/Perl instead of Windows/Cold Fusion.  We had never used Linux/Perl before, but one of our employees said, “I can do it, I  know Perl.”  Sometimes, the desire for money gets the best of your judgment and you say OK.  It was just this one engineer doing the job without help because he was the only one experienced with Perl.  If it was in Cold Fusion, the job would have been pretty straight forward for us.

The Wagonwheelwagonwheel1

It was like he was building a wagon wheel.  He knew what a wagon wheel was, but he had never built one before.  He knew the basics of wood-working, but no one in the office understood wood-working and could not help him.

The first thing he did was build the wagon wheel hub.  Then he built the spokes.  And finally he built the rim.  They lay the ground in front of him.  A smile beams brightly on his face.  “How’s it coming along?”, I inquired.  “99% done!”, he declared.  “I built all the components and now I just need to put them together.  I should be done in a few days. ”

As he put the spokes into the hub, he noticed that one of the spokes had a burr on the end and would not fit smoothly into the hole in the hub.  I noticed his annoyance and I asked what was wrong.  He said, “No worries, I’ll just saw the edge off the spoke and the remaining piece will fit. 99% done.  I should be done in just a few days.”

The plan seemed sensible.  He cut off the end and the spoke fit. He then put in the rest of the spokes.  No problems.  Then, he tried to put the rim around the end and noticed a problem.  The one spoke with the burr was shorter than the other spokes.  It didn’t reach the rim.  I noticed his annoyance and I asked what was wrong.  he said, “I know what to do.  I’ll saw the other spokes to match the shorter one.  It’s no big deal.  I’ll get it done in the next few days. 99% there.”

I started to get nervous as the project was getting late, but the engineer seemed confident.  He sawed of the ends of the other spoees to make them all match.  They all fit the hub.  He then tried to put on the rim, but realized that the diameter of the wheel had shrunk.  The shorter spokes make the rim too long.  It would overlap.  He slammed his hand down on the desk.

I noticed his annoyance and asked what was wrong.  He said, “The rim is too long now.  I know what to do.  Ill saw a bit off the rim to make it smaller.  It will be easy.  I should be done in just a few days.  99% complete.”

This pattern kept going until he had a pile of sawdust and no product completed.  At some point, he started vomiting in the middle of the night.  Eventually, we told the customer that we failed and gave all the money back.  The employee quit after nearly having a nervous breakdown.  This was the worst project we ever worked on.  99% the whole way.

The Symptoms

  1. Trying to do a project with tools you are not 100% confident (done it before with success).
  2. No one around to help who has #1 covered.
  3. Missed deadlines.
  4. Always at 99% done.


When you think you are in a wagonwheel project.  Quit.  Quit quickly.  Do not wait until you have a nervous breakdown.  This is bad for business, bad for the customer, bad for everyone.  When you want to learn a new technology, don’t do it alone and don’t do it for a paying customer.

Engineers often forget to put QA time into their estimates.  In other words, they are optimistic by nature.  Also, business managers are even more optimistic because they don’t know what can go wrong.  Everyone needs to try to be objective.  Things will go wrong.  Many things.  Leave room for QA.  For every day of engineering, there is a day of testing.  Otherwise, you will blow your deadlines.

This is a good story to tell managers and engineers.  Programmers will get it from experience.  Managers will get it on intuition.  I hope it helps.

Whatya think?