Re: Project management melee

From: Mladen Gogala <>
Date: Wed, 13 Jun 2012 17:06:53 +0000 (UTC)
Message-ID: <jrahbd$f50$>

On Wed, 13 Jun 2012 21:33:41 +1000, Noons wrote:

> Hmmm..... Always the same problem: engineering quoted incorrectly.
> Bulding roads is engineering. The waterfall method in the diagram does
> not apply to engineering although it looks very nice. If there is ONE
> thing that was hammered into me in 6 years of studying engineering in
> uni, it was:
> feedback loops and their importance for ANY project.
> Engineering is all about feedback and how to control it and take
> advantage of it. Nothing to do with mathematics, although of course
> those are required for the deterministic aspects of engineering.
> The biggest problem with agile methods - and indeed most modern aspects
> of software development - is that they are not based on ANY sound
> engineering principles. Feedback or no feedback, there is a LOT more
> that is wrong with those methods than just feedback. For starters, few
> use the most basic checks and balances on their execution and results.
> Nothing to do with engineering.
> Software development used to be a discipline of software engineering.
> But because that is expensive to train people for - and nowadays what is
> needed is heaps of developers capable of cut-and-paste tons of code -
> things have slacked off.
> Ah well, who cares? DBAs have been cut-off from any responsibility in
> IT,
> mainly as a result of Oracle's constant disparaging and deriding of that
> job in the last 10 years. Don't be too surprised to find that DBAs
> really don't give a hoot anymore about Oracle. Or any database, for
> that matter: they're just tools to be used and abused by any would be
> newb damager with a "kewl" "method"
> approach.
> Cynical, mwah? Never!...

Noons, please observe that neither of us, both proud DBA 0.9B types, is out of work yet. I don't have an engineering background, my major was in math, similar to Cary Millsap, so neither Cary or me are qualified to speak about the engineering principles.
My critique of the agile method, applied to DBA projects, is very simple: agile methodology was developed to keep pace with the ever changing requirements on the software. There are three principal means how agile achieves this:

  1. Small steps and short cycles controlled by the PM who is given almost a godlike power in the agile shops.
  2. Lots of communication to provide feedback: daily sc(r)um meetings, sprint retros, buddy exchanges, inter-team meetings
  3. Adopting team building practices and tactics, like buddy programming. Agile development is a team sport, just like rollerball, only rougher.

There is a significant overhead related to agile methodology: all those meetings, documentation requests and "team events" are eating up the project time. The problem with agile methodology applied to the administrative work like database or system administration is that administrative projects do not have ever changing requirements. If I am to upgrade the production database to release, that is a well defined project which has its usual phases: functional tests, dry runs, QA, UAT and implementation. Using agile methodology for such projects is a waste of time and likely to seriously annoy system, database and network administrators. That is why Cary's friends were telling agile jokes in the restaurant.
On the other hand, there is a visible knowledge problem on the application development side. For years now, colleges are spewing out Elbonians who only know how to use Java, Hibernate, EJB and Tomcat or JBoss, with a philosophy that "database doesn't matter" and the ambitions of developing "database neutral application". That has lead to an enormous waste of resources because the applications simply do not perform as expected by the damagement. What is visible nowadays is a whole lot of job ads asking for a "development DBA". Other companies use "embedded DBA" method: DBA is "embedded" with the development team that needs the services for a month or two. Usually,the crucial power of vetoing the development design isn't given to the "embedded DBA" (sounds a lot like "secret boss", but even more st00pid). The DBA is still subject to all agile time wasting rituals, which breeds discontent and cynicism.
To make things even worse, the agile shops usually employ a very laid back management style. Everything is handled by the PM, so there is no need for the director to allocate resources, set priorities or do much at all. The net result is that agile shops not only have huge problems with applications performing poorly, they frequently use obsolete software and are overstaffed because "we believe in people". Cary Millsap is, as John has mentioned before, an incredibly smart person. He is, however, leaning more to the software development side, which is understandable knowing his history at Oracle. He is not a DBA like Tom Kyte, Ken Jacobs or Charles Hooper. Disparaging as Oracle is to the role of the Oracle DBA, it still didn't succeed in making it go away. Simply put, when things go bad, there must be someone capable of fixing it. Such capability usually requires both knowledge and experience. And that is not going to go away anytime soon, today more than ever.

And you are right about one final thing: just like many of my colleagues, I no longer care about Oracle Corp. If given an opportunity, I will gladly replace it with DB2 or some other competing RDBMS. That is a rather general feeling among my colleagues that I'm still in contact with. The practices of the Oracle Corp. today are strongly reminiscent of Microsoft in its "800 LBS gorilla" years, when Ballmer was complaining of the "stench of Unix" when forced to adopt BSD socket library.

Received on Wed Jun 13 2012 - 12:06:53 CDT

Original text of this message