Author Topic: Design is Pure - Really?  (Read 4573 times)


  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
Design is Pure - Really?
« on: February 25, 2008, 03:51:19 PM »
Several years ago I worked with a software designer who loved to remind me (the implementor) that "design is pure, implementation is fallible".  It should then come as little surprise that when anything went wrong, the problem - at least to him - could never have been due to any of his efforts because (and again) "design is pure, implementation is fallible".

I've been reminded of this recently with a few projects where the initial request and the final result were next to nothing like each other.  The requests started simple enough with something like "I need X" but upon further discovery X was not nearly as straightforward as the designer first believed.  In fact, in a few cases what was requested was merely a side effect of what was truly needed.

So who is really at fault in these situations?  Is the designer at fault for not having all their ducks in a row at the start and leaving the implementor to sort out the details?  Or is the implementor at fault for creating a solution that might not adapt to changing requirements as readily as one might desire?

I say nobody's at fault.  Here's why: While neither design nor implementation are any more "pure" or "fallible" than the other, one of the most dangerous trends I've seen in business in the past dozen years or so is an increasing amount of time spent finding blame vs. discovering a solution.  While it's a beautiful thing when a design is rock solid before implementation, more times than not the process of taking that first step towards the solution is exactly the spotlight that's needed to illuminate the potholes along the way.  As long as everyone is on the same page regarding the end result, this level of understanding and acceptance of the "back-n-forth" can be a significant boost to productivity.  Always remember, the greater the productivity, the greater the results - and often with less total resource commitment.

When an error does occur it's certainly important to know why, but ONLY in the context of preventing it the next time.  So go ahead, take a moment to look back, formulate a plan so it doesn't happen again, and then turn your gaze back to the future, because that's where the real progress is happening.
Accidents "happen"; success, however, is planned and executed.