Monday, April 8, 2013

G is for Generalization

This year, for the A to Z Blogging Challenge I'm posting alphabetically on topics related to software development...

Last time, I talked about future-proofing.

Generalization is a useful form of future-proofing. It involves thinking beyond what the business folks are telling you, and looking for ways to abstract ideas that might get stretched in future.

Opportunities for generalization often show up when your business users start listing off sets of possible values for data entities. Examples: "We've just got the head office here, and the store downtown." "We only sell this in red, white, and black."

Those are giveaway clues that you should have a table for those kinds of things, and not make assumptions that would limit future additions to the table.

Some opportunities are a bit more obscure, because they seem to be wedded to the way things work. Suppose a payroll system has a field on the employee record with a "W" for weekly-paid employees, and "M" for monthly. A short-sighted approach would end up with programs littered with decisions along the lines of 'If it's a "W" do this, if it's a "M" do that...'

Instead, a good generalization is to set up a table of pay cycles with the code (e.g. "W") along with some additional data to describe how employees of that type should be treated (e.g. "pay every 7 days, on a Friday").

The aim of this is to make sure that nowhere in your programming do you directly encode facts like 'If it's a "W" then today must be a pay day'. That question is always answered by looking up the pay cycle record and doing a calculation based on the associated data. And the aim is to make that calculation as generally-useful as possible. In the case of pay cycles, you might for example allow concepts such as "every x days" or "every x months" and some way of showing when the cycle ends. This might sound like a lot of effort, but the point is it is only going to be done once, in one place, so you can afford some extravagance here.

Why is that a good thing?

Imagine your business owner comes into your office one day and says, "Look, I know I said this would never happen (**), but management has just agreed to a new grade of staff, and - get this - they will be paid every two weeks!"

Do you want to be heading for coronary country imagining all those places where you encoded that M/W decision?

Or do you want to smile, add a third pay cycle to the table, and say "Done"?

(**) This is another giveaway phrase: The more strenuously a business user insists it won't happen, the more likely it will.


  1. Seems like your theme could be really useful for anyone working in this field or interested in getting into it. Good theme!

  2. I know nothing about software development, but I think it's a great theme choice, and I wonder ... could you expand it into a non-fiction book for publication? :) Thanks for stopping by my blog!

  3. Just stopping by for the A-Z Challenge. Please check us out and sign up to follow if you like what you see. Juliet atCity Muse Country Muse

  4. ** goes with "He doth protest too much!" I suppose? :) Ornery programs simulators and if only there was more standardization or generalization as you said...

    Happy G day!

  5. Trisha, I also hope it's of interest to folks not in this field - some glimpse behind closed doors.

    Margo, it did cross my mind :)

    Ornery's Wife - too much protestation is a warning sign, for sure!

  6. I really should have my husband read your blog as he is a software designer and he married me, not a maths person, artistic, not into details, more macro than micro. But thank you for visiting my blog.


I love comments. Please feel free to join in the discussion.

I also try to respond to comments. I usually do so during the early evening (Pacific time) which may be many hours away from now!

So if you leave a comment and return some time later and I haven't responded yet, please don't think I'm ignoring you. I'm not. Honest.

Related Posts Plugin for WordPress, Blogger...