Friday, January 23, 2009

The Sin of Generalization

The more I progress in my journey as a software engineer, the more I realize how our profession suffers from the Sin of Generalization. The good news is that this sin can be fought with a rope and a mast. Let me explain.

This almost deadly sin manifests itself in two ways:
  • A tool or a methodology that has been sucessful in one context gets generalized and becomes applied to other contexts, where it ill fits.
  • A generic platform or framework is created to solve all sorts of needs, while ad hoc solutions would have been more straight to the point.
This may sound funny from me, as I am the lead of NxBRE, a .NET generalized rule engine! The reality is that NxBRE, like all rules engines and al generalized tools, has a sweet spot where its usage makes sense. Outside of this sweet spot, using a generalized tool is in fact counterproductive, because the indiosyncracies it is bringing (limitations, bugs, specific configuration...) outweight its benefits.

Of course, there is value in re-use and generic tools. The point of the matter is that it is always worth considering the relevance of a generic tool or methodology everytime you intend to use it. This sounds like an obvious statement but experience shows that generalized solutions are as attractive and noxious as sirens.

Hence the rope and the mast.


Nick Zhu said...

I just got out of a contract working on a online gaming platform. The CMS system the architect designed in this project was so generalized the developers all refer it as a "glorified database editor" :-D

I guess the nerd in all of us has this tendency to over reuse stuff we create or like. For me I found just-in-time and just-enough design and development usually address restrain myself from going that direction.

David Dossot said...

Thanks for sharing your experience, Nick.

I should have mentioned in my post that the temptation goes both wayd: using a generalized solution is tempting but creating one, a la ├╝ber-framework, is also a temptation that runs deep in our nerdy veins!

RT Kaushik said...

Modeling the various Statutory deductions to be done from a salary - is using Business Rules a good idea for this ?

I have read stuff on BRMS all over the place as well and your post on Generalization is where, I have paused to wonder whether BRMS is not meant for this?

Though I still see the Tax Rules as Rules, which should be decoupled from code and stored as Business Rules.

Sorry if this post is not the perfect place for this, but I could not find any other place to seek your opinion on this

David Dossot said...

RT, you may very well be in the sweet spot where a BRMS makes sense.

While evaluating BRMS versus ad hoc software development, consider the following:
* amount of rules,
* volatility of these rules,
* complexity of these rules.
* probability that non-developers will look at them/edit them,
* support for change management (versioning, validation, deployment),
* technical idiosyncrasies.