DBA or not DBA

For some reason this industry seems to be confused about the role of the DBA.
It has always been my opinion, and the opinion of every Oracle based software house I've worked at that the DBA's roles are simple to define.

The DBA is responsible for:

• Ensuring the continued running of all databases under their supervision.


• Minimising the impact / time of any maintenance induced downtime of those databases.


• Minimising the risk of databases becoming unavailable for unplanned reasons.


• Minimising the impact / time of any unplanned downtime.

You may notice that I don't include in that list anything to do with development.

The DBA is not, and should not be regarded as a developer. That's not to say that any given DBA would not make a great developer. Many DBAs I've met would make great developers. Rather it's that the two roles are intrinsically different. You'll notice that my definition of the DBA roles are very similar to those of a second or third-line support team member. Most organisations involved in software that are large enough to have a dedicated support team would split the roles of support and development for everything other than the database. So why should the DBA and development roles be treated any differently?

Make a DBA a developer and you'll cost yourself development time whilst that DBA fixes issues on live systems that simply can't wait...

Technorati Tags: Oracle, DBA, software+development

Sentence of the day

Overheard in the kitchen:

The only thing that hasn't changed is that things are changing

Back to Oracle

Category: UpgradingOracleDatabases

In Extreme Programming Explained (2nd edition), Kent Beck references Pramod Sadalage's elegant incremental design strategy:

• Start with an empty database.


• Add all the tables and columns with automated scripts that also migrate any existing data as necessary.


• Sequentially number the scripts so a database at any earlier stage can be brought up to any later stage by running the scripts.

This idea is extremely (pun intended) similar to my own thoughts on the same problem, though I think it misses a couple of points. I'd prefer to see it written more like:

• Start with an empty database.


• Add all the tables and columns you need for the current piece of work with automated scripts that also migrate any existing data as necessary.


• Surround each script in tests that cover the pre and post conditions. The pre conditions cover your assumptions about the database required for the script to run, the post conditions cover the requirements for regarding the script as 'complete'


• Sequentially number the scripts so a database at any earlier stage can be brought up to any later stage by running the scripts.


• Make sure a failure in any script (including its pre or post) stops the rest of the patches from running


• Make sure you can run all the patches from a single command

If the system you're developing sits on top of a legacy system then your build will start with an import of a set of live data into an empty schema, the upgrade as covered above and then the tests for the rest of the application can run against a system that closely mirrors the target environment.
If the live data is so huge it takes to long to do the upgrade as part of the regular build you've got three options:

• Tune the upgrade so that it is quick enough


• Reduce the set of data you import so you have the right texture of data on a smaller scale


• Run the full import and upgrade in a less frequent build

Ok, ok, so it might not be so elegant as Pramod's way of putting it, but it's complete...

Aside: If you've not read XP Explained, read it NOW. If you've read the first edition, but not the second, read the second edition NOW. If you've read both, think about reading them both again!

Technorati Tags: oracle, extreme+programming, Kent+Beck, Pramod+Sadalage

Developer Factory

Gotta say, I'm enjoying Object Thinking. David West is a bit of an evangelist but it's difficult to argue against many of his points.

One such point is that eXtreme Programming isn't about creating high quality software, it's about creating high quality developers. The by-product of having high quality developers is that high quality software is produced. I'm worried that tight fisted IT Managers might get their hands on this thought and start charging training costs to employees for working in an XP environment, but it is a good thought none-the-less.

It's also something that each developer should bear in mind when working in that XP environment. Every piece of work that's done is an opportunity to become a better developer. You're in full time training. Sometimes you're the trainer, other times you're the student. Most the time you're both. By sitting back and explaining certain assumptions you find flaws in the those assumptions. By teaching people what you do and how you do it, you spot problems more easily. Plus, of course, there's someone sat next to you that will tell you when you're wrong.

It's a thought I've always had lingering in the back of mind, but it's probably always been 'Me Teacher, You Student'.
I'm wrong, and I need to learn to change that attitude. We're all learning and improving the way we work through our interactions with other.

When we forget that we've got a lot to learn then we start going backwards again.

Technorati Tags: extreme+programming, David+West, pair+programming

Good conversations...

There's one going on over here.