- A Famous Feud
- Conflict at Fever Pitch
- Team Design Without Gunplay
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Conflict at Fever Pitch
While not reaching the deadly proportions of the Hatfield-McCoy feud, some IT feuds rival them in fever. Teams that are supposed to work together don't. Specifically, database administrators (DBAs) and developers (don't call me a programmer!) often butt heads and fail to find common ground. In the clan wars of West Virginia versus Kentucky, the motive was no less than the Civil War. In the case of DBAs versus developers, it's all about control.
The fight is usually determined by the software team's makeup. I've seen shops divided in two primary ways when there's a dedicated DBA team:
- DBAs are in charge of all data design and T-SQL.
- DBAs inherit the design and have to maintain the database servers.
Option 1: DBAs Do Design
In the first team arrangement, the first pain point involves the design. DBAs are in on the design meetings, and create databases, tables, views, and other objects. The developers have their own design in mind—something they feel would be far superior and make their jobs easier. The DBAs design for what they perceive as speed and maintainability. Strike one.
The next pain point is the coding process. Developers need to move data into and out of the database, but DBAs want to enforce security and standards. They create stored procedures and views, which don't always make the developers happy. The DBAs store raw data, making the developers transform it in code, causing them more work. DBAs have control of the system; developers don't. Strike two.
The final straw happens when the support calls start coming in:
Developer: "It just can't be the code I wrote; there must be a design flaw in the database. What do those DBAs know about good coding anyway?"
DBA: "The database is the problem? Perish the thought. That thing is designed so well it's scary. If you'll take a look at your code, you'll definitely find that it needs optimizing. The very idea."
Strike three. Get my shotgun.
Option 2: DBAs Inherit Ideas
So obviously the better team design is where the DBAs just keep the systems maintained, right?
Wrong.
In this situation, the third strike happens anyway, and the DBAs take the calls. Frustrated users bash the DBAs, and the developers shrug and say, "Are you sure you have the right indexes? You probably don't have the right indexes." The developers are far too busy writing code to be bothered with support, and don't those DBAs have some free time to take the calls? After all, the only things they have to do are designing an index here and there and doing our backups. And isn't all that automated anyway?
Now the DBAs feel like second-class citizens, having to clean up a mess of a database that was designed improperly to begin with. They have no idea why a stored procedure was coded that way, or the reason it's the highest-costing statement in the batch. Is that just a function of how much data there is? Could the access be done another way? You sure can't ask the developers. You know what they would say.
Get me my shotgun.