Engineering or Customer Service which is more important?

I’ve been reading a lot about lean/toyota way lately, mixing that with my past experience as an IT Consultant and throwing that up against a bit of an Ivory tower I fell into with XP that left me unable to deal with the following scenario:

You’re reviewing code either yours or someone elses right before release. you find the code strewn with anti-patterns and uncessary conditionals. You are due to ship tomorrow. The code works but is not maintainable, do you ship?

My instinct as a software developer has been “don’t ship” for as long as I can remember. I’ve taken my teams on some week long trots down engineering principle lane.  While this has its place, I feel not shipping for ivory tower excellence is a critical mistake. The focus must be on satisfying the customer first and foremost, and it is absolutely critical to be aware of our limitations at the time. The most Lean and disciplined organizations (even Toyota themselves) realize they cannot do everything in an ideal way all the time. As new learning and knowledge is put together they will revisit and refine these problem areas over time.

Therefore, my approach at this time is to:

  1. review why the problem occurred
  2. strive to prevent the problem from happening in the future
  3. If the software is still delivering value to the customer to provide them with the product
  4. Tell the customer of any limitations have been found that affect their perception of value
  5.  Work on a plan to correct the issue in the next release (which should be soon). 

I’ll admit I don’t have this all figured out, but I’m reasonably certain that my old approach of delaying a release because only pristine code should come out of the team was only helpful to my ego.  Engineering is fanstastic, but we’re in a service industry first.

About Ryan Svihla

I consider myself a full stack polyglot, and I have been writing a lot of JS and Ruby as of late. Currently, I'm a solutions architect at DataStax
This entry was posted in Lean. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • charlv

    Hi Ryan,

    Yeah, unfortunately we are always in the situation of delivering what the customer wants or delivering the best engineered solution. They almost never meet.

    In terms of your problem of discovering bad code just before release, the first thing that comes to mind is perhaps to have your code review earlier in the cycle, i.e. just after check-in or just before.

    The second step would be to introduce some check-in policies which the developer(s) must adhere to before checking in the code. Some tooling can also be introduced to automate some of the checking for you.

    Hope it helps and good luck.


  • @charlv agreed. it was a completely avoidable screw up.

    Been thinking about using NDepend to flag certain conditions post check-in as a help, but I don’t think it completely replaces the need for a good code review.

    Ideally we’d do pair programming but I’ve never been able to fully sell that principle into the system.

    Thanks for the suggestions.