Rules in Software

Following on from Paul’s post about rules in software…

So why do we have rules in software?

  • It makes things easier – developers can switch off their brain, apply the rule and get back to surfing the web.
  • Consistency – thing are done in a standard way throughout the code base, but of course this includes doing the wrong thing everywhere.
  • Safety – it gives developers some insurance, when some asks “why the hell did you do X?” a great answer is “it’s the rule, we have to do X”.
  • Pseudo silver bullet – we’re still looking for it aren’t we, there are lots of people who think that if we apply enough rules, standards, processes that a project cannot possibly fail.

The problems with rules are that they

  • Can be misinterpreted – for example, after explaining the refactoring of extracting a method to replace a comment to a colleague he proceeded to remove comments from the code-base as he had interpreted this as “comments are bad”. It was a combination of my poor explanation and him not thinking about why we would want to do this and when it should be applied.
  • Can be exploited or circumvented – as soon as a rule is in place developers (those crafty devils) will find a way around it or use it to their advantage. I’ve heard of a project where the rule was that all Java classes and methods must have Javadoc comments. The reaction of the developers was to write a tool to automatically generate them with meaningless contents, but the rule was satisfied.
  • Can rarely be applied without judgement – a rule in software development in many cases has an opposing one that can be just as valid given another situation, so the decision is never simply black or white. For example many of the refactorings provided in Martin Fowler’s book have an equally valid opposite one e.g. “Replace Delegation with Inheritance” and “Replace Inheritance with delegation” so which one to use requires some judgement. Will it make the code better or worse?

So I’d like to replace Paul’s rule “There’s no such thing as a rule to rule them all” with the more different rule.

“Question every rule”

I’m not sure there should ever be any hard and fast rules in software. A typical day for a developer involves lots of small decisions being made that will improve the code and it’s design in some way and should never be blindly applied without thinking about why and weighing up the pros and cons.

Advertisements