Use The Right Tool For The Job

It’s taken me a long time to learn some of the common-sense ideas that most people pick up in kindergarten. I was reminded recently of the wisdom in the idea “Use the right tool for the job.”

A customer contacted me and asked me to look at a heavily-modified spreadsheet. Up front, I have to give props to the programmer. It was a piece of art. It pulled in data from different sources, used advanced queries to manipulate and sort, and did quite a bit of complicated filtering and reporting.

The customer wanted to step up to the next level, and tackle some very difficult data from a source that wasn’t friendly towards the methods used in the code. The customer’s programmer wasn’t real sure which direction he should go in order to accomplish the request, so I was called in.

After reviewing everything, and understanding the customer’s request, and the programmer’s methods, I came to the conclusion that I simply couldn’t help the customer.

The problem wasn’t that we didn’t have the skill. The problem was that Excel simply couldn’t represent the data any better than what was already being done. The programmer had extracted every last bit of programming mojo out of the spreadsheet. Excel simply couldn’t represent the data in the multi-dimensional fashion that the customer wanted.

Clearly, the data should have been data based long ago. A database solution would have made the customer’s request a mildly complex query. Instead, a lone programmer resource had devoted several day’s worth of FTE hours towards forcing Excel do the job.

It demonstrated to me that when all you have is a hammer, every problem tends to look like a nail. The customer insisted on Excel, because that’s what she was familiar with. The programmer was focused solely on making it work within the boundaries of the customer’s limited perceptions, instead of what the best tool for the job was.

This lesson in wasted time and jury-rigged solutions has resonated with me since then. I told myself to be aware of the limitations of the tools in my toolbox. When the capabilities of a certain tool are outstripped, it’s time to man-up and tell the customer what needs to happen to protect their data and bring the project in under deadline.

Other lessons? How about telling the customer what’s best for their project, instead of what they want to hear? Or, knowing the capabilities and limitations of your tools? Or, thinking of the goal of the project, instead of the method that the customer thinks they want?

What do you think of this? Do you have a similar experience where the tool being used on the job was clearly not the right one? How would you have handled this differently? Have you ever tried to make a certain tool work, even after the project had clearly outpaced it’s capabilities? Sound off in the comments please!

Regards,

p.s. I REALLY like getting and responding to comments. Please click the {comments} link below this post to leave me some!

photo by casers jean