Habit #5. THE BLAME GAME: "Don't look at me, it's developer's fault that SQL is in production"

Some DBAs have a real "us versus them" mentality when it comes to developers in their organization. They see themselves not as facilitators helping developers develop quality code from a database standpoint, but rather as guardians who prevent poor-quality code from making it into production. This might seem like semantics, but a confrontational relationship between developers and DBAs results in a lack of developer initiative and significant slowdowns in release cycles.

Cures: Select DBAs who understand it's their responsibility to work as an integrated team with developers they support. Cultivate a team attitude by structuring continuous DBA involvement in every project rather than at review milestones. Consider assigning an individual DBA in a developer support role. If it's clearly in job description, there's more motivation to do it well.

Habit #6. THE SOLO ACT: "I know what I'm doing and don't need any help."

Database administration is increasingly complex and even most senior DBAs can't possibly know every last detail. DBAs have different specialties, which need to be culled and utilized. When DBAs feel like they know, or should know, everything, they don't ask questions and miss out on valuable knowledge they could be gaining from others.

Cures: Foster a teamwork culture where it's acceptable for DBAs to admit they don't know answer and to ask for help. Encourage your DBAs to seek out an outside peer group as a forum for brainstorming and testing their assumptions. No single person can match expertise and experience of even a relatively small group. Provide a safety net of tech resources such as reference materials, courses, and outside experts or consultants on call.

Habit #7. TECHNO-LUST: "Things would work so much better if only we had..."

DBAs are often on top of latest technology, which can help them do a superlative job. But when desire for new technology causes DBAs to recommend unnecessary hardware purchases or software add-ons, costs tend to skyrocket quickly—as do problems.

Cures: Never upgrade your hardware infrastructure without first exhausting all tuning opportunities. Remember, ten years ago enormous enterprises were run on servers one-tenth capacity—all thanks to necessity and skill. Never consent to using advanced or new features until you're well aware of ongoing maintenance commitment and resulting costs. Watch out for DBA support software that presents friendly GUI interfaces for difficult tasks. This type of interface allows a beginner DBA to act as an intermediate DBA under certain circumstances, but simultaneously prevents that beginner from learning actual skills behind tasks. Moreover, these tools tend to hide real risks from DBA, making potentially damaging activities as easy as point-and-click.

Whether it takes a twelve-step program or one tiny adjustment, all of these deadly DBA habits can be kicked. Of course, first step is recognizing problem. By starting with this list and doing a careful inventory of successes and failures in your team's database administration, you'll be well on your way to finding a cure.

Don't blame developers. It's more likely a project runs over budget and over deadline because of optimistic cost planning or scope creep than poor developer skills. Following these rules ensures delivery of best product development team can achieve within a set budget or period of time. Even in an environment where scope creep becomes a factor, escalating requirements can be scheduled into minor versions so they never hold back launch of "functionally challenged" application.

Testing? Who needs testing? So you didn't follow six rules, you're past code freeze date, and you're supposed to be in final testing but there are still more things to implement. The user community and CEO want to know if you'll be able to launch on time regardless. That's when it hits you— if only we could "streamline" testing phase we could still make it. Very bad idea. The cost of backing out due to insufficient testing can cost more than project itself. Recently I witnessed a botched implementation of a customer service application that almost cost company in question its three largest clients—and millions of dollars.

Work your mediation magic. Application development managers have to be part negotiator and part magician. They need to keep all sides happy, even if product expectations and budget restrictions are in conflict. No one really wants 70% solution, but everyone can live with it. And when no one's 100% happy, you know you're probably doing it right.

Read more in Case in Point: "The Thursday Rule"