Re: Project management melee
Date: Thu, 14 Jun 2012 12:40:31 +1000
Message-ID: <jrbiuu$unk$1_at_dont-email.me>
Mladen Gogala wrote,on my timestamp of 14/06/2012 3:06 AM:
> agile methodology was developed to keep pace with the ever changing
> requirements on the software.
Right here I disagree with agile. With the results, not the initial concept. I have yet to see ANY agile development project that has been able to cope with ANY change halfway through! Sure, it can adapt to the latest "kewl" tech. But once there and initiated, if anyone so much as peeps of a change in the design, it's major "re-factoring" time. AKA, major re-development time. Sorry, but that is as far from software engineering as it can get.
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.
Ah yes: the AppleMac development mantra. "Do as I do and say as I say or else get out". Any fool can make that shtick, because it is based on hiding ANY problems by the PM. IOW: no impartial accountability, no checks and balances, just blind faith.
> 2) Lots of communication to provide feedback: daily sc(r)um meetings,
> sprint retros, buddy exchanges, inter-team meetings
Yup. They're the ones in our office that meet every morning, then at the end of
the meeting yell out very loudly and disturbing everyone else in the building:
"3-2-1-TEAMWORK!"...
Have yet to see any service request actioned by them in less than one month.
I guess that's "teamwork"?
> 3) Adopting team building practices and tactics, like buddy programming.
> Agile development is a team sport, just like rollerball, only rougher.
Which basically means: if someone is completely wrong, the entire team will help propagate that wrongness and defend it to the death. Like I said: no checks and balances, anywhere!
> There is a significant overhead related to agile methodology: all those
> meetings, documentation requests and "team events" are eating up the
> project time.
My word, how true!
> 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.
Yeah, but when the only one doing the checks is the PM - who couldn't possibly have a self-interest in smoothing out any issues? - one can see what the result will be...
> 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.
Yeah. "Problem management by hiding". Back when I started in IT, anyone with such an approach would sufffer the tar-and-feathers treatment. Nowadays, they receive industry awards...
> 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".
Don't get me started on "We cannot use Oracle: that is not strategic for the company. We must use software that is supported and of relevance in future, like ruby-on-rails"...
> 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.
Funny thing is: no matter how many times that gets proven, time and time again, there is always a moron somewhere who tries to "prove" it wrong...
> 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.
Well, they were warned - MANY times! - that their stupid marketing strategy of dumping on dbas was akin to shooting themselves in the foot - dbas were the very people who pushed for Oracle everywhere. Welcome to reality.
Same here: I have trouble finding a dba that will recommend or chose Oracle,
nowadays. And I DO help run a SIG dedicated to dbas. Unlike Oracle's own user
group who has been abismally absent from any dba-related activities in this
state for the last 10 years.
So much for "actively promoting the product and the company", eh?
Wasn't that the fundamental criteria for "acedom" at some stage?
(Any wonder why I point-blank refuse to participate in that silly charade?)
Received on Wed Jun 13 2012 - 21:40:31 CDT