Heh... most of the companies that have hired me to fix things, have rooms full of developers that hate "old style DBA's" or think they know things like what Agile programming really is. The reasons the companies hire me is always the same... the system is not maintainable... the system and the related apps are too slow... they keep loosing data... it takes too long to deploy new apps... it takes too long to even find a problem, never mind actually fix it... when people leave, the learning curve for new hires is too steep... they run out of disk space... backups take way too long... etc, etc, etc. And, they don't even know what a deadlock is never mind fixing and preventing them.
Jeffrey Irish probably said it best above... having developers, whose only goal in life is to get the job done no matter what, because the boss said so, IS very much like having the "inmates run the asylum". If you think that having a traditional hybrid DBA interferes with Agile development, you're absolutely incorrect... getting the hybrid DBA's involved in Agile Development is the best thing you could do because they can make things happen more quickly because they know the system 100 times better than most developers and they can do it with great fore thought to prevent problems in the future simply because of their knowledge and experience.
Would you let a person who maintains go-carts and has never seen the guts of a Ferrari tune your Ferrari? I wouldn't think so... and you certainly wouldn't use the same fuel in the Ferrari as you do the go-carts.
Databases aren't just a place to store data... they are an engine and it doesn't matter how many bell's and whistles you hang on the mirror of a car, if the engine doesn't work right, the car goes no where fast or, worse, may leave you stranded where you can least afford it. It's the same with every business... the data is the only thing that allows a business to stay in business. Protect it. Let (hell, INSIST) the DBA's do their job even if you think it's not "Agile"... they might even save your agile butt in the process.
Two of my favorite examples of what I'm speaking of follow...
When I arrived at my previous job, they had an average of 640 deadlocks PER DAY with spikes to as many as 4000! Customers were constantly complaining about the "deadlock victim" messages they were getting. Management and the developers had been working on the problem for months. They even called in so-called "experts" that told them to convert all of their cursors to Temp Tables and While Loops, which they spent a huge amount of money and time doing. The deadlocks never waivered... maybe even got a little worse.
The System DBA's knew exactly which routine was causing the problem. It turned out to be a very simple "GetNextID" routine that would get the next PK ID for a group of tables from a "sequence" table. We made a very simple change based on database best practices and a little known ability of the Update statement... the day we implemented the change, the deadlocks dropped almost to zero. Keep in mind that this was a problem that management and the developers had been working on for months and had expended close to a half million dollars on.
Now, if the DBA knew so much about the problem, why didn't he fix it? Heh... he was told that he wasn't a developer and couldn't touch the code. They wouldn't even entertain his ideas.
My other favorite problem of this nature is a "dupe check" written in an Agile fashion by developers. The goal was to check 93 separate databases (1 for each day... another design by developers) to see if there were any dupes in a particular table in each database across all the databases. The table in each database contained anywhere from 3 to 6 million call detail records EACH. The developers designed a "system"... it took 24 hours to usually fail and they could only go back 2 months (62 databases) instead of the required 3 months (93 databases) because it just took too bloody long and there was a month-end SLA with the PUC and some of the financial departments that absolutely had to be met (interpret as huge fines if not met).
After I totally rewrote the dupe check system, it would do all 3 months (93 databases) in 15 MINUTES! No, that's not a misprint... the methods I used brought a job down from 24 hours to 15 minutes all while doing 50% more work. And, it's NEVER failed in the two years that it's been in operation.
Remember... the original system was built in an Agile fashion by developers... not DBA's.
I've got hundreds of other examples... and the current job I've recently landed is no different. I'm working on some POP code (Proof-of-Principle code) to demonstrate a single stored proceedure that replaces an entire ETL subsystem. Their method currently takes 40 minutes for a particular type of file. My POP code currently takes about 90 seconds and that's without me looking for any tuning opportunities.
If you think "old style DBA's" are contrary to Agile, you're just dead wrong.
If you think they slow things down in the development process, you're probably right... it takes just a bit of time to do it right so you don't have to do it over and over and over every time there's a minor change in scalability requirements. While it's certainly an important consideration, the reduced "Time to Market" provided by Agile should NOT be the only consideration.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs