“I need a database designed, which will not only clear up our current order processing issues, but will make our processing 1000% more efficient …”

The manager had that charismatic gleam in his eye that makes you just about believe anything he says.

“… and I know you guys can do it…”. Just as our data architect and the rest of the data team begin to sit up in grateful anticipation, the manager finishes his sentence “…by Tuesday…this Tuesday”.

And why not, he probably thought as he airily waved us out of his office. After all, it’s just a case of filling out a few tables in the design tool, drawing some lines between them and hitting “generate”, right? In that light, the Tuesday deadline seems overly generous!

This is, of course, the stereotype of the quixotic nature of managers and their unrealistic dreams which has been immortalized by Scott Adams so well that it is hard not believe that it is reality: but is isn’t entirely fair. While managers sometimes eschew common sense to push their underlings to exhaustion, we DBA/programmers, even the most practical ones, are equally to blame for having unrealistic expectations of what we can achieve in a given time.

The problem is that many DBAs estimate a project in terms of their capabilities alone and the speed with they could complete their part of it. Many of us are passionate about what we do, to the extent of being hobbyist DBA/programmers in our spare time. Yes, working alone, I could have that database designed and coded in the next seven days! What many a DBA fails to do is pause, and to identify carefully every step required to complete the project, and then estimate, realistically, how long each will take.

How long will it take to discover the real business requirements that underpin the boss’s overriding requirement to “get it done”? How long will it take to asses and refactor any existing code? How long for testing? And so on. Inevitably, it turns out that other people will be involved with the project too. For example, what about a usable interface for the customer that has to be created after the database is designed and built?

Realism includes the ability to make a proper estimate of how long a project will take, or indeed, will cost. Every DBA would like to implement their systems to 99.9999% uptime, but we have to be realistic in terms of what that means for costs, maintenance windows (or lack of, since 99.9999% uptime means less than an hour of downtime a year!), manageability, and staffing to be on alert 24 hours of every day of the year. Is it realistic? It can be, but depends on the need and the budget, and nothing else.

As with most things, realism improves with experience and becomes instinctual. Your idealistic inner hero lives in (dis)harmony with your curmudgeonly inner bureaucrat, exhorting caution and realism. Some companies still exercise a kind of “enforced realism”; once you suggest a time you stick to it, even if it means 18-hour days plus weekends. The more progressive employers reach a better understanding of a project’s timeline using techniques such as planning poker.

Regardless, in a company that manages productivity realistically, our manager’s request would have ended with laughter and “seriously, though, how much do you think we can finish by this Tuesday or do I need to ask for more time?” Either that or he would have started with “Once upon a time…“

On March 13, I will present a webinar on why being observant really counts for a DBA. You can sign up here: http://www.red-gate.com/products/dba/sql-monitor/entrypage/sql-monitor-what-counts-webinar