Shouldn't managers have more empathy for what we development-DBA types suffer in pursuit of high-quality databases? Every cry of "how much longer is it going to take?" or "are you done yet?!" grates on the DBA like the five-year-old in the back seat of the car screaming "are we there yet, are we there yet?" Don't they understand our predicament? The complexity of the task? Why can't the average manager appreciate our earnest struggles to produce software that is worthy of our training?

These thoughts used to boggle my mind. Early in my career, I decided quickly that all managers would be a lot more tolerable if only they understood, and cared more about, what I went through. It was only later, with a few more years under my belt, and lumps on the back of my head, when I came to realize that I, like many programmer or DBAs, was also a major part of the problem. I had no empathy for what my managers went through, and what they really needed from me.

When I have a task to do, I tend to care less about how long it will take and more about making sure I do it right. I pride myself in being skilled and quick at what I do, but if doing a task right takes twice as long as I expect then, it just does. Database development has a subtle difference from application-development. It is not as easy to fake your completion dates, i.e. using technical debt (a.k.a. dirty hacks) to meet a deadline and then quietly filling in the gaps later. In a database, this is a sure route to invalid data, missed orders and unhappy customers.

We can tweak the structure of a database, further down the road, as long as we start out right, and the basic design is sound. It is very hard to refactor a database that is fundamentally wrong, once there are clients attached. The true lack of quality in a database design isn't apparent from quality metrics. It is only once the database is loaded with a few hundred thousand rows of data and subject to a highly concurrent workload that the real problems associated with poor design rear their head.

If getting the design right, first time, leave schedules and dependencies all out of whack, so be it, surely? Well, not really. Even if it means I did my part "right", I have likely failed in my larger responsibility to my manager, and to the team. Clearly if all a manager did was empathize with my need for perfection, then the only deliverables would be requirements documents, prototypes, and a stack of expense reports for the training I needed to make sure I knew what "right" really meant, in cases where I wasn't sure. There always has to be compromise. The best database design is not one that's perfect; it's one that is good enough and can be built in the allotted time.

The difficulty for managers is that their performance is assessed based on the completion step of the process. How long it took, how good the interface looks, and how loudly the customers praise or condemn the final product are the measuring sticks. So, while clearly they do have some empathy for your efforts towards achieving the best possible database, it's tempered by the knowledge that the biggest catastrophe would be to produce nothing at all. Without the user interface code being delivered on time, the most perfect database design, the greatest indexes, and the perfect single query with 142 lines of text is completely worthless.

So, the next time a manager is screaming at you about deadlines, remember that it's probably not because of a lack of empathy or a desire to compromise on quality. It's because they are trusting you to understand the definition of "good enough".

Louis Davidson (Guest Editor)