What Counts for a DBA – Empathy

Every project I am on, there seems to be a common argument. The project manager is pushing to get done faster, and we software producers are pushing back for more “quality” time. Shouldn’t managers have more empathy for what we development-DBA types suffer in pursuit of high-quality data? 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 more 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/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 don’t really care how long it will take. I pride myself in being skilled and quick at what I do, but if to do a task right takes twice as long as I expect then, in my eyes, it just does. Database development has a subtle difference from application-development. You can’t as easily fake your completion dates. Using technical debt (dirty hack code) to meet a deadline and then quietly filling in the gaps later can lead to invalid data, which could mean missed orders and unhappy customers. Databases need to be started out right, right from the beginning. It isn’t easy 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, right? Well, not really. Even if I did my part right, I have likely failed in my larger responsibility to the team.

Clearly if all a manager did was empathize with my need for perfection, then the only deliverables that that would be produced would be requirements, prototypes, and a stack of expense reports for millions of dollars of training so I could make sure I know what right actually means where I am not 100% clear.

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 fail to produce anything 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.

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. So 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 entrusting you with the definition of “good enough”.

Note of course that this is but one characteristic of many that I have covered so far, and I am certainly not advocating just giving in to a dictator who doesn’t care about quality. I am simply noting that most managers are just people who have a job to do. If we can at least give a little understanding, it can go a long way to fostering a good relationship with management, just like delivering quality solutions will make even the hardest manager soften to your needs over time.

How you log in to Simple Talk has changed

We now use Redgate ID (RGID). If you already have an RGID, we’ll try to match it to your account. If not, we’ll create one for you and connect it.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.

Continue

Simple Talk now uses Redgate ID

If you already have a Redgate ID (RGID), sign in using your existing RGID credentials. If not, you can create one on the next screen.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.

Continue