Friday, February 03, 2006 

Work Smarter, Not Harder

It was a management mantra in the late '80s - early '90s, and as such, it has got a bit of a misnomer :-) among developers. I distinctly remember it being used even on the Dilbert strip (from the pointy hair manager, of course).
However, that was a good advice indeed. In the past two days I've been consulting on a data replication - sinchronization - fusion problem. There are a number of issues involved, including a legacy system with severe data quality problems (data is not really in a format that makes this kind of stuff easy, and changing structures is a difficult, costly, error-prone activity). Currently, deployment is quirky to say the least.
I contributed with a few good ideas, changing long, manual, error-prone procedures into short, automatic, safe procedures. I also brought back attention to the data quality issue, which was no longer consided part of the problem, trying to draw a roadmap to gradually move outside the quagmire. At the end, we had a short-to-long term stratey, consisting of six steps, each one bringing some improvement at a reasonable cost (and risk). I'm confident we will take the first 3 steps. Steps 4 to 6 may or may not see the light, depending on future business & technological issues (and on human factors as well :-).
All this required thinking outside the box. Weinberg, in his "precision listening" concept, told us to watch out for absolutes, like "this can't be done". Sure it can. We just need to find a way :-). Too often, we don't see a way because we're trapped by linear thinking. Still, we can spare ourselves a lot of hard work by finding creative solutions, requiring little manual coding. Actually, I don't believe in hard-work in programming. If we're working too hard (I mean long hours of pure coding, bug fixing, patching around fragile systems, etc) often we're not looking hard enough (or haven't been looking hard enough :-) for a better way to do the job. [Or we overpromised, either by lack of technical or managerial skills, but even there, often we've not been looking hard enough for a better way to get the job :-)]