The software developer's generalisation dilemma

By Grant Jacobs 12/11/2011 4


xkcd nails it :-

I find when someone's taking the time to the right in the present, they're a perfectionist with no ability to prioritize, whereas when someone took the time to do something right in the past, they're a master artisan of great foresight.
I find when someone's taking the time to the right in the present, they're a perfectionist with no ability to prioritize, whereas when someone took the time to do something right in the past, they're a master artisan of great foresight.

It’s the classic dilemma, isn’t it.

Faced with coding a new bit of functionality, do you write the version that solves only your immediate problem or do you think ahead and try cater for future, more varied, uses too?

Perhaps you want to find that middle ground; lay it out enough that the opportunity for future generalisation is documented well enough and sufficiently in place so that you can move on in peace, having noted the opportunity and laid the tracks for future development without having expended too much effort.

At least that’s what I generally aim for. (Initially.)

I see it as a professional coder’s challenge. Or just a productive coder’s challenge. To remember to code for the client, or your objective, and to push distractions aside, interesting as they might be. Interesting sidelines can turn into a form of procrastination otherwise.

Put it another way: not on their dime, unless you care confident you can deliver ‘something extra’ that they’ll appreciate without ruffling feathers. It’d be like the cartoon otherwise.

Footnotes

Don’t get me wrong. I love the idea of giving more than was asked for but a reality, for independent developers like me at least, is that you have to be careful of overhead time. By only briefly sketching it these out in documentation, etc., in the main run of things elaboration is pushed to overhead time, where you’re more likely to be critical about implementing it or not.


Other articles on Code for life:

Research project coding v. end-user application coding

Life sciences want bioinformatics, but not so much e-infrastructure?

How algorithms shape our world

Literate and test-driven programming (in bioinformatics)

Developing bioinformatics methods: by who and how


4 Responses to “The software developer's generalisation dilemma”

  • I go for third time around gets generalised.

    If asked to do something once I do the absolute minimum. If asked for something similar the second time I think about generalising. When asked a third time, I provide a general solution (if that is possible).

    This behaviour is borne of experience. There are a great many cases where the general case does not need to be solved.

    I wish I could convince my co-workers of this more often though.

  • I guess with time we all develop rules of thumb for these sorts of things; the slight differences in those “rules” may reflect different niches.

    I ‘document quickly and move on’ to capture my thoughts at the time without losing too much time over it partly as it sometimes can be a while before I return to any one code module and it’s easy to forget what seemed obvious at the time. Obviously, I prefer code with plenty of notes & documentation!

Site Meter