Prod DBA 2.0 says no**

Dominic Delmolino has made a welcome return to regular blogging and it’s good to see that I’m not the only one forgetting the basics.

In the body and comments of Dominic’s*** first few posts back, the subject of database development is very much in focus.

So, DD got me thinking and here is my stream of random ramblings – they jump about a bit, it must be a Friday.

Production DBAs have no place on most development teams!

When was the last time you saw a production DBA in a scrum standup? (Genuine question – do you do that?).

Today’s production DBA is a busy man whether he’s 0.x (seen a lot of these), 1.0 (met a handful), 2.0 (heard tale of a few) :)

Some might say they’re too busy coming up withinsane “policies” and standards.

At the very least, even if he has automated everything that he can automate(*), with the vast estate of DBs that a small, modern production DBA team *should* be able to support, the ebb and flow of urgent production issues means that he’s unsuited to the predictability of the resource availability that modern agile project development demands.

That vast estate of DBs that a small, modern DBA *should* be able to support also means that the knowledge that the production DBA of any one specific application or schema tends to be very limited.

However, for most enterprise-level data-centric applications (caveats and clarities due to previous sweeping statements), the data model is still so important and it’s just not being done right in so many places.

Here is a link post to a selection of other writings on the subject.

What Dominic D says strikes a chord with me. (But I’ve got a vested interest. The role he describes is essentially what I do or what I try to find.)

Most agile development teams (caveat again – most agile development teams developing enterprise-level data-centric applications) need access to a database development specialist.

Someone who knows SQL, knows PLSQL (in the case of Oracle), knows performance and knows the features and functionality of a database ideally to at least the same level expected of a production DBA (albeit with different peaks and troughs in specific areas) but without the irregular demands on their time from urgent priorities.

Most of them need this to be able to build data models that scale.

And to keep everyone on track with the data model and the big data picture – this can quickly get lost in translation especially with commodity developers (plug and play).

Most of them need this to write or at least QA SQL and PLSQL that will scale.

Most of them need this to strike a balance between new features and stability.

Most of them need this as a regular interface to the production DBAs as a communication conduit and filter, and to uphold the requisite standards and policies for development to move into production.

And absolutely this database specialist should take full responsibility for what goes into production – it’s all about control and responsibility.

Two other thoughts occur (and I’m not sure I’d finished on the previous thought but it’s gone now, flushed).

Firstly, and I commented this on DD’s blog, there is belief that all developers are equal and that you can plug and play any developer into any project without any consequence. I don’t believe at all in this approach. I’ve never seen it work effectively apart from in the presentation layer – i.e. coding input fields and buttons, etc – and even then I’m far from convinced.

What I am definitely convinced about is that this in no way works for any layer that requires significant business knowledge and goddamit does that include the database.

On the subject of the second of the two thoughts mentioned above, the phone rang before I could write it down and so that thought has now disappeared. If I remember, I’ll update this. Until then my mind’s gone blank….

Update:
Oh yes, the second thought. Development DBA is sometimes the starting point for a junior DBA – en route to the production DBA. This is a nonsense given the control, responsibility and knowledge required. As mentioned they need to know at least as much as the typical production DBA.


*I’m not a production DBA. Never have been. And although I’ve thought about it, not sure I want to be. Development’s where it’s at for me. But how DBA teams have much automated? And automated well? Everywhere I’ve been recently, the DBAs are firefighting constantly. Or they’re refreshing environments. Or they’re just completely overloaded with stuff that sounds like it should be automated. I mentioned this to someone else recently and they commented that it was because a large percentage of the production DBA team were contractors and has no vested interest in automating. I don’t know if that’s true. Any thoughts? There should be no greater compliment than going into a company and improving it to such an extent that the manual intervention you were providing was no longer required. But I can see the conflict.

**Prod DBA 2.0 says no -> Not sure how many, people outside the UK are familiar with Little Britain. Think it was way overhyped myself, followed by way overplayed. Personally (as comedy appeal always is), although there have been exceptions like the Armstrong and Miller fighter pilot sketch, there’s not much sketch comedy that has regularly and consitently tickled my fancy in the last decade since the Fast Show.

*** Confusing – am I referring to Dominic Delmolino or have I taken to the convention of referring to myself in the third person.Did you know that the latter is known as Illeism? I didn’t.
Stylistic device or a form of narcissism?
My CV is in the third person and I’ve never been even 83.2% happy with that approach.
But I’ve never liked it when I’ve rewritten it with a personal pronoun – “I” – neither with the modern trend of no pronoun whatsoever, e.g. “Worked on an oil rig. Implemented XYZ. Put out lots of fires.”
It stems from my time at a consultancy – that was their style.
Then again, I don’t agree with the narcissism interpretation (e.g. a bit like celebrities and some sports persons).
If anything, for me at least, it’s completely opposite – a form of anti-narcissism, a self-demotion which I think of as being particularly British.
It can be easier to say “X achieved this” than “I achieved this” and maybe there’s a comforting distance between this CV character “Dominic Brooks” and myself?
Don’t know if there’s an established phrase of “take the blame but share the glory” but maybe it’s something like that …

Database Agility

A collation, for my benefit, of the thoughts of some others in this area:

YAGNI?

YAGNI, it’s a very common term in development teams these days. Overused even.

However, in today’s more austere and economically challenging times, I have some new acronyms for you.

I’m not really up on popular acronyms so these may already exist in some form or another, but here are some more appropriate sayings that I’m saying/seeing more and more, together especially:

I Do Bloody Well Need It (IBLOWENI – ha ha) … but … NO-one’s Gonna Pay For It (NOGOPAFI).

Flexible demand-driven development

Outsourcing small projects or using some management strapline like “flexible demand-driven development model”, it never works.

This is the Nth place I’ve worked where they’ve decided that to be able to supply the non-linear development needs of the business, the next solution to try is to outsource individual projects to “strategic development partners”.

In my experience, this solution is normally the third to be tried after

  1. Hiring and firing contractors in line with demand. This never works because business knowledge is key to decent development. You can cope with a few business-agnostic resources but not many. And I would say that it takes at least six months before you start to get comfortable with most business knowledge.
  2. Outsourcing to bodyshops on the subcontinent. I reckon this never works either because of many of the same arguments above. Plus the time differences affect your communication.

And so, you get in some onshore or near-shore “development partners”. If you’re lucky, this works the first couple of times because your development partners put on their industry-specific high-rollers but then it’s not long before the quality degrades. Even if you’re lucky, the headaches of integration with existing in-house systems, differing standards and ongoing support are too big.

Unfortunately, I’ve not seen the solution anywhere yet. It’s a crisis that IT is still working through to find the solution, although I suspect that, until the magical system comes along with you draw some boxes and lines in Visio and then something builds your whole system, it’s about being more realistic about what the IT department can deliver in the time, no matter how unpalatable that might be.

Follow

Get every new post delivered to your Inbox.

Join 62 other followers