Do the Needful

So the last few blogs have been a bit negative and have been built around common expressions and assumptions that make my hackles rise (If it ain’t broke, don’t fix it, We’re Risk Averse and Best Practice). Now this is the blog with the positive spin, so it might seem strange that I’m hanging it around this faintly irritating epithet. I’m minded of emails I’ve received along the lines of

The database is running slow. Please do the needful

Doesn’t give you a great deal to go on. Even assuming that “the database” gives you enough info to decide which environment, server, instance and database we’re talking about, “running slow” doesn’t give a lot away. Running slow compared to what? Running more slowly than yesterday? Half an hour ago? This time last year? And what were you doing when it started to run slowly? Etc., etc. etc. We’ve all been there.

But perhaps it’s unfair to take umbrage at the lack of info being supplied. We (and I’m not just talking about Triton Consulting, but all of us who are DBAs) put ourselves forward as subject matter experts. We’ve all worked in the industry for yonks; seen databases designed beautifully and seen them “designed” in a manner that suggests someone tossed a manual into a room full of chimps. We’ve worked on different versions and editions and seen the product grow and mature and become so feature rich that no one brain can hold all the details.

I once interviewed a guy for a DB2 job; to replace me as my contract came to an end. I was there to ask a few tricky technical questions and I put one to him and he said “ooh, I don’t know; hang on” and reached into his briefcase to get the syntax manual out. Now I thought that was a perfectly reasonable response and what you would probably do in an operational situation. Unfortunately the manager running the interview did not and he was escorted from the building.

What I’m getting at here is that technical support is making more and more demands in terms of our knowledge. If we’re going to take advantage of the vast palette of options that DB2 now presents us with, we’ve got to be fairly immersed in the product and have experience of all the features and options it has, as well as having experience of the gotchas and traps for the unwary that inevitably exist in a product this complex.

DB2 is not just aimed at the blue chip Industry giants but at the small and medium scale enterprises who may not find it economic to have someone with that amount of experience sitting around. If they’ve got large scale development and significant support requirements; then, maybe, yes. But if they have a relatively stable product with a minimal requirement for change then that might be harder to justify.

You will still need certain pro-active checks on the health of your database, you’ll still need someone around to do an upgrade once in a while, you’ll still need to be able to call on someone if there’s a critical problem, you may still want a few hours, or days, or weeks of SME time to produce a specific solution or to service a specific application development. But that might (might) not justify a full time body, or bodies.

So the next time you’re given scant information on a problem or a requirement and asked to “do the needful”, maybe it should be taken as a compliment and a recognition that you’re the go-to expert and that the person sending you the request is acknowledging that they really don’t have any idea about your area of expertise, as they’ve got too much on their plate with their own speciality.

• Share