Better than your average programmer…

There was a minor discussion about enums, constants and branching on a project discussion forum recently.  Alternative options suggested included polymorphism, delegate hashes and factories.  One of the responses suggested these were beyond “the average programmer”.

 

That’s crazy talk that leads straight to the ivory-tower.

We just need to expose people to the alternatives as often as we can.  Expand their normal

 

So here I want talk about evolving towards a more change friend solution using the scenario of calculating bonuses that is similar to what was being discussed in the forum.

Warning: the code below was not run.  While it’s meant to be javascript, it’s not meant for copy, paste, execute.

The YAGNI Solution

 

This is certainly readable and understandable.  It’s also crazy simple and likely to get more complicated.  When that happens, how do we transform the problem?  How do we use the alternatives so that when one part of the problem changes, the entire solution does not in churn?

The Less Cohesive Solution

 

We’ve moved the calculation into it’s own area.  That’s pretty nice.  But it seems likely that when criteria change, so will the calculations.  When one thing churns so will all others.  We’ve spread around what it means to get a “Great” review.

A More Balanced Solution

What would be nice is if adding, changing or removing any single bonus category was self contained.

 

At this point, what we find as the point of churn (each business decision) is now isolated.  The contract between the entry point of calculating the bonus and the actual calculators is in the registerCalculator implementation.  We’re assuming that won’t change much.

More Code != Better

This is not a hammer for all of your business decision nails.  It is certainly more complex.  But we must balance complexity, cohesiveness, and correctness with all the other things we value.

The first solution is not “bad”.  I would ship that first solution.  I’d adjust my system over time so that change was enabled in my architecture.

  • Tom McKearney

    So, you’re not a big fan of the YAGNI approach?  I find, more often than not, people who say “YAGNI” or “KISS” have difficulty designing/implementing at the higher levels of abstraction needed to support future efforts.  

    Thus, they tell everyone “I’m being Agile” instead of “I’m a hack” :)
    (OK: a bit of hyperbole in there, but.. kinda true)

    • http://twitter.com/cromwellryan Ryan Cromwell

      “So, you’re not a big fan of YAGNI approach?”  - I don’t think you read the whole thing :)

      I’m not  sure I follow your second part.  If you’re saying people you I’m being Agile, YAGNI, etc as a cop-out for quality and discipline then I agree it does happen.  Then again, people also use quality and craftsmanship as a cop-out for actually shipping.  It goes both ways.

  • Tim Larson

    When something is beyond “the average programmer”, then that is an excellent opportunity to help that programmer become better than average.  

    If you don’t keep learning, you’ll get left in the dust very quickly.

  • Tim Larson

    When something is beyond “the average programmer”, then that is an excellent opportunity to help that programmer become better than average.  

    If you don’t keep learning, you’ll get left in the dust very quickly.

  • Tim Larson

    When something is beyond “the average programmer”, then that is an excellent opportunity to help that programmer become better than average.  

    If you don’t keep learning, you’ll get left in the dust very quickly.