The Seven Deadly Habits of a DBA... and how to cure them

Written by Paul Vallee

Continued from page 1

Habit #5. THE BLAME GAME: "Don't look at me, it'srepparttar 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 helpingrepparttar 137552 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 withrepparttar 137553 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 inrepparttar 137554 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 evenrepparttar 137555 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 knowrepparttar 137556 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 matchrepparttar 137557 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 ofrepparttar 137558 latest technology, which can help them do a superlative job. But whenrepparttar 137559 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-tenthrepparttar 137560 capacity—all thanks to necessity and skill. Never consent to using advanced or new features until you're well aware ofrepparttar 137561 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 learningrepparttar 137562 actual skills behindrepparttar 137563 tasks. Moreover, these tools tend to hide real risks fromrepparttar 137564 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,repparttar 137565 first step is recognizingrepparttar 137566 problem. By starting with this list and doing a careful inventory ofrepparttar 137567 successes and failures in your team's database administration, you'll be well on your way to finding a cure.

Since the company's founding Paul has been Pythian's key trouble-shooter for our toughest technical challenges. Before launching Pythian, he worked as an Oracle consultant bringing his vast expertise to various companies across North America.

The 70% Solution: Practical Testing and Version Control

Written by Steve Pickard

Continued from page 1

Don't blamerepparttar 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 ofrepparttar 137551 best productrepparttar 137552 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 backrepparttar 137553 launch ofrepparttar 137554 "functionally challenged" application.

Testing? Who needs testing? So you didn't followrepparttar 137555 six rules, you're pastrepparttar 137556 code freeze date, and you're supposed to be in final testing but there are still more things to implement. The user community andrepparttar 137557 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"repparttar 137558 testing phase we could still make it. Very bad idea. The cost of backing out due to insufficient testing can cost more thanrepparttar 137559 project itself. Recently I witnessed a botched implementation of a customer service application that almost costrepparttar 137560 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 wantsrepparttar 137561 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"

Steve has degrees in Mathematics and in Management of Information Systems from Ottawa University. Before founding Pythian, Steve worked as a consultant for numerous companies as well as the Canadian government. He remains the key architect of Pythian's highly sophisticated internal applications and business process systems.

    <Back to Page 1 © 2005
Terms of Use