- 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
Team Design Without Gunplay
So what's to be done? How do we fix the problem? Is there any team design that works?
Sure there is. The first thing is for everyone on the project to treat everyone else on the project as an important member of a team. Not just lip service, but really treating everyone's opinions as valuable.
The DBAs simply have to be in on the design. I can see a few developers out there cringing, because you've seen junior DBAs who simply don't understand application design. If that happens to you, help them learn, and do it with respect. But you've got to have them in there during the design meetings.
DBAs are experts in data management, and will keep your design honest—not just on the feature set, but on the maintenance of the system as well. Not only that; having DBAs participate in the design helps them to understand why you want the database to be shaped in a certain way.
If the DBAs are really good, you definitely want them in the design meetings. They'll keep you honest, and keep you doing what's right instead of what's right now.
If your shop is like the second case and the developers are going to write all the T-SQL code, your DBAs need to do a code review. Don't scowl like that. They need to do it for two reasons.
- Although you might not believe this, developers do make mistakes from time to time. You use a spell-checker in your word processor, don't you? It may not change your sentences, but it does question some of the words. A good code review should work the same way. Maybe you meant to write the code that way, or maybe you need to take a second look at it. If you don't have a good reason for why you wrote the query that way, you probably shouldn't write it like that.
- Don't think DBAs can code T-SQL as well as you? Let them review the code anyway—and learn. It's vital to train everyone on your team to spot good (and bad) code. Keeping the system code all to yourself means that you're the only one who can maintain it. Is that really what you want?
DBAs, you're not off the hook. If you want to be treated like a professional, act like one. Learn everything you can about databases and design—and, yes, even learn a programming language or two. You might even find a civil developer out there who likes helping others learn.
Don't be afraid to admit that you don't know something. If you're not sure why a table or query is designed the way it is, respectfully question it. A good developer can defend his or her code, and won't be offended at the question if you ask it politely.
If you're a DBA who controls the system, be responsive. Usually a developer has a really tight schedule, and if you drag your feet on the project, developers will fight you. If they can make the case that you're the bottleneck, you'll have a bad day. Trust me on this one: Even if you never get confronted about the problem, it's noted. That doesn't bode well during review time. So work with the developers, and help them as much as you can.
Finally, team leaders need to be aware of the running feud brewing in the trenches. I've even seen some that are aware of the feud and allow it to continue, thinking that conflict is good. Nonsense! You're supposed to be leading a team, so lead it. Encourage the free flow of ideas and communications, and everyone will be happier for it. And you might even get a well-designed, supportable application out of the process. As an added benefit, no one will get shot.
Probably.
For more information on SQL Server, visit our SQL Server Reference Guide or sign up for our SQL Server Newsletter