All these years I thought DBAs were the least liked group inside of IT. So imagine my surprise to find out today that data architects are seen as roadblocks to productivity as well.

I simply had no idea. I am shocked to hear this.

On the other hand, the article reinforces a theory I have had for years: developers hate everyone, apparently.

Digging deeper into this I believe I have found the following facts to be true:

Developers Don’t Want Perfection

As a DBA or a data architect it is our role to lay out the ideals to be followed. As a result of seeing these ideals laid out before them, many people (developers, project managers, pointy hair bosses) see those ideals as too time consuming to be followed.

You want two or three testing phases? Impossible, we have deadlines to meet.

You want to use specific datatypes? Impossible, it would take us months to classify everything properly, and we have deadlines to meet.

You want to know how much data we are expecting? We have no idea, we have deadlines to meet and we need to get started coding now, why are you wasting our time with all these questions?

[Besides, we all know that the business requirements are going to change anyway, so we might as well start building something and worry about the requirements later, right?]

To me the first issue is the nature of how IT projects are almost always under the gun due to a time constraint. It’s always “by the end of the year”, or quarter, or month that a project needs to be completed. There is little to no time to worry about making it perfect, it simply needs to be considered “delivered” in order for people to be considered to have met their objectives for the year when it comes time for their annual review.

Developers Don’t Want To Waste Time

So now that the developers have started building something the last thing they would want to hear three months later is that they need to start over. Who wants to be told that they have wasted their time? Nobody, that’s who.

This is where I break out the term “structural integrity”. [Yeah, it *is* something I heard many times in many Star Trek episodes, so what?] Anyway, whatever it is that gets built is only going to be able to go so far, or so fast (i.e., scale). Three or six months down the road, as all the requirements are changing and performance isn’t being met, the last thing the developer wants to hear is that they should have listened to the DBA or data architect in the first place.

It’s like having to hear someone say “I told you so”, except you can’t punch them in the face after they say it without having HR get involved.

So how do we avoid this? With better project management, a better setting of expectations, and an understanding of what is needed versus what is wanted.

We all want perfection, but perfection is not always needed. Sometimes you just gotta get started on building/fixing something.

You’ve got to look past all those trees and just see the forest, you know?