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?
Disclaimer: I’m a developer who occasionally gets mistaken for a data expert, project manager, QA person…
I have been trying to wrap this up in a clever sentence for several years. There is definitely a class of developer that believes that writing the code is the most important aspect of IT and product delivery and that anything outside of writing the code is valueless or serves simply to slow them down. This often includes any type of data architecture, database administration or guidelines, documentation, project management, testing (quality or unit), usability, UI design, and so on. It occasionally includes software design as well. “Cowboy coders” is probably the closest I’ve managed to come for a term. My wife, having worked as a receptionist at a software development company, has less nice terms (the ability to punch code into a computer does not grant you genius over all topics of conversation or suddenly free you from having to clean up the sugar you dropped on the floor).
On the specific case of architects, there is the stereotype of the ivory tower architect, who sends down airy-fairy designs that are unnecessarily complex or unrealistic. While I think there are definitely a few architects that work this way, in more cases I think there is simply a disconnect between the architect and developers. While it would be nice to wave a wand and fix the immaturity of the developers viewpoint towards their role, it’s probably more realistic to try and help them understand why the architecture or forethought is necessary and the risks that it will help mitigate or value it will enable (at which point they will immediately try to solve the problem for you because developers like solving problems, but that’s a different conversation).
Ultimately I think it comes down to helping them understand that pounding code is not what we/our company/whoever is paid for. Backups are useless, it’s the restores that provide value. Code is useless, it’s the end user acceptance/usage that provides value.
Eli,
Thanks for the feedback. I also believe that better communication is key here. Part of that is the proper setting of expectations for all parties involved in these projects.
Seems pretty similar to a marketing/sales relationship–mutually symbiotic, and forever recalcitrant with regards to synchronization. For us, two things have helped both sets of battles: 1) switching every team to an agile scrum model
2) creating interdept teams for what are, after all, interdept-affecting projects
Claire: how has the agile scrum approach worked out? Would be interested to know more details, especially how it turned out now it is 9 months since you left the comment. We have separate development teams using agile and waterfall, with architecture stuck in the middle.
Developers don’t always have data skills. You see this a lot more on other platforms.
On the Microsoft side of life, developers are encouraged to invade our camp and frequently do with varying degrees of success. I have an example in one of databases: he named a table ‘Transaction’. The offender is long since gone and happend before I appeared on the beat. Now even his fellow code monkeys scoff at such an interesting choice since they are stuck escaping the reserved word everytime they want to write a query. Truly — I’ve thought how interesting it’d be to name a table ‘table’, a function ‘function’ etc., but I digress.
Anyway, doesn’t DBA stand for ‘Don’t Bother Asking’? With a little effort we can take ’em!
First, I have found that, in smaller operations, Data Architects, Data Administrators and DBAs have a love/hate relationship. I have had great respect for the architects and DAs I have worked with, but I have argued with them more than anyone else.
One corollary I have to add it, now that I am in a large, highly structured company, we don’t get to talk to each other much, so it does work differently (and I miss it).
But I have to agree with the comments on developers. They are rated on how quickly they get things out the door. As long as they don’t explode as soon as they get into production, they have done their job. Problems which come up later are for production support to address.
David has hit on the main reason for conflict between architects and developers: we are measured and compensated for different goals. Data Architects for emphasizing data quality and endurance, developers for getting code up and running fast.
These two conflicting goals are the basis of almost all the debates I have with developers…until we all realize the reason we have a difference. Then the debates become negotiations. While I don’t like negotiations, I find it a lot easier and more fun than edicts or wars.
My goal on a project is to get developers to at least respect me and to love the data. If I can get that, I’m happy.
There is only 1 answer…
DO IT ALL YOURSELF – DESIGN, DATABASE, GRAPHICS, PROGRAMMING – oh AND I SOMETHIMES TYPE WITH CAPITAL LETTERS SO OTHERS DON’T IGNORE ME ALTOGETHER. I’ve been oxymoronically called a “Stupid Geek” before and that person didn’t last long in their job let me tell you now.
PEOPLE, DO IT ALL YOURSELF AND STOP WHINING ABOUT STEREOTYPES.
No two DBAs or DEVELOPERs, or PROJECT MANAGERs for that matter, are the SAME. This article is disgusting the way it pigeon-holes people, you’ve made me feel utterly sickened with your generalisations that come nowhere near applying to me. The real problem with the world is exacerbated by silly articles like this… lay people need to GET A CLUE about WHAT they’re talking about before they BLAME someone else or cry uselessly that “it doesn’t work” ! Developers don’t hate everyone, they just hate it when someone who uses the app everyday can’t feedback properly about a bug, they just say, again, “it doesn’t work” there is nothing more anti-constructive and indicative of “I have to use a computer in my job but never bothered to learn how to use one properly” … this is why developers get so frustrated and sometimes believe they’re above everyone else, it’s because, in some ways they are above everyone else (but not all of course that would be proof of a really bad supremacy complex). And whether you like it or not, WRITING CODE correctly is the most DIFFICULT thing to do in the whole world of grassroots computing – if you don’t believe so, then you’re NOT a developer and stop pretending that you have any idea how hard it really is. Developers don’t need to think the are smarter than everyone else, if they do then they are not really a good developer after all, more a pretentious self-righteous dimwit which can happen to YOU too, no matter what walk of life you step. PLEASE Stop picking on DEVELOPERS unless you’ve actually tried to do what people like us do. You won’t know what you’ve got til it’s gone, typical greedy human colours.
Um…wow…OK, perhaps you missed this line in the article:
“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.”
Sorry to have sickened you. Perhaps you are unfamiliar with how the internet works, how it is full of opinions, and how some of those may differ from your own.
Feel free to browse elsewhere.
Awer: “And whether you like it or not, WRITING CODE correctly is the most DIFFICULT thing to do in the whole world of grassroots computing”
Maybe for you. And maybe that’s a sign that you’re not quite in the right profession. (Although I’m not sure I’d recommend politician as an alternate career choice.)
Awer, is this you?
Karen: I agree with the economic basis of your argument, but I’d frame it in the more abstract term incentivized versus compensated. Its not just about money or continued employment, its about pressure, peer perception and other intangibles as well as the next paycheck, promotion, bonus and review.
Awer: Doing it all yourself is a good option sometimes. Also, code is not the hardest thing to do in a project. Few can code, but few can also sell an idea, or set priorities. Yes some jobs are easier than others. Programming is harder than working a level one help desk. However, its much easier to write a simple crud app with 100,000 concurrent users than it would be to run a support desk for those 100.000 users.
This one’s going on our internal “community” site Monday morning. There are certain developers in our organization who need to see this.