Re: Project management melee
Date: Wed, 13 Jun 2012 17:06:53 +0000 (UTC)
Message-ID: <jrahbd$f50$2_at_solani.org>
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:
- Small steps and short cycles controlled by the PM who is given almost a godlike power in the agile shops.
- Lots of communication to provide feedback: daily sc(r)um meetings, sprint retros, buddy exchanges, inter-team meetings
- 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 11.2.0.3, 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.
-- http://mgogala.byethost5.comReceived on Wed Jun 13 2012 - 12:06:53 CDT