Is there any joy left in this industry?

[Mark Woodward]

On 10/29/2010 12:45 AM, discuss-request-mNDKBlG2WHs at public.gmane.org wrote:
 > Date: Fri, 29 Oct 2010 00:45:10 -0400
 > From: David Kramer <david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org>
 > Subject: Re: Is there any joy left in this industry?
 > To: discuss-mNDKBlG2WHs at public.gmane.org
 > Message-ID: <4CCA5156.1030702-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org>
 > Content-Type: text/plain; charset=ISO-8859-1
 >
 > On 10/28/2010 10:24 PM, Mark Woodward wrote:
 >> > On 10/28/2010 12:00 PM, discuss-request-mNDKBlG2WHs at public.gmane.org wrote:
 >>> >> Date: Thu, 28 Oct 2010 00:42:02 -0400
 >>> >> From: David Kramer<david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org>
 >>> >> Most things made for 25 years become commoditized as the hard 
problems
 >>> >> get solved, eh?
 >>> >>
 >> > Perhaps, but I can't believe that there aren't any "hard problems" 
left.
 >> > There are plenty, but the industry has basically decided to fight over
 >> > commodities instead of growing the environment.
 > OK, go do it!  What's stopping you?  I did it.
I'm actually in recovery mode from my last entrepreneurial excursion. 
The economy has been very rough. I don't believe digging in the same 
holes is going to make anything any better. I had a GREAT idea, but I 
saw a form of it on amazon and am re-evaluating other ideas.
 > I gave you several examples of companies.  Of course there aren't as
 > many as there used to be.  The combination of the bad economy and the
 > fact that very few executives are thinking more than a quarter or two
 > ahead makes companies more conservative.
If "conservative" is a euphemism for "short sighted," yes.
 >
 >>> >> I will agree that a lot of very stupid things are being done in 
the name
 >>> >> of Agile that are not Agile at all, but that's not the fault of 
Agile.
 >>> >>
 >> >
 >> > Here's my problem with Agile, the Agile proponents claim it is a good
 >> > system, but decry that when people do it wrong, its the people's fault
 >> > and not "Agile."  A system or practice that depends completely on the
 >> > the people doing it right for success isn't really a system. The 
fact is
 > Uhm, so you're saying if you do Agile wrong and you fail, it's Agile's
 > fault?  "Doc, you told me to take one of these pills a day, but I felt
 > really bad so I took 8, and now I have a stomach ulcer, so I'm suing 
you".
Its not quite the same thing, is it? Its more along the lines of a diet. 
If you follow the rules of the diet and don't lose weight, its a bad 
diet. Similarly with Agile, if you follow the guidelines it doesn't 
actually help unless YOU know what you are doing.

 >
 > Requirements gathering, software design, software development,
 > integration, testing, and deployment are all hard problems fraught with
 > innumerable opportunities for failure.  Yes, if you do it wrong, you
 > open yourself up for a world of problems.
Ahh, that's the thing. Agile does nothing to address the fundamental 
problems of software development. I don't know if you know many members 
of AA, but I have sort of an analogy. (Appologies if it is, well, 
politically incorrect)

IMHO, there are two kinds of AA members. The people biologically 
addicted to alcohol and can't shake the need for a drink. These are the 
people AA can help deal with their problems. Then there is the other 
type, the ones that have other issues like anger and other "self 
destructive" behaviors. They have used alcohol in the past as an excuse 
and now they are in AA "working on themselves" by staying sober and 
never, EVER, look at the issues that actually make their lives hard. You 
should see the movie "Changing Lanes" for an example.

The most successful "alcoholics" in my life, are the ones that go to AA, 
get their life in order and realize that if they don't get out, they'll 
be lifers.

But I digress.

Agile may fix (if done right!) a small subset of the management of the 
software development process. If you already have a dysfunctional 
process and team, however, agile does not help.

 >
 > Any practice that is so fault tolerant that you can do it poorly and
 > still succeed is trivial as to not be comparable to the business of
 > developing software.  The coffee maker at work isn't even that fault
 > tolerant.
 >
 > Waterfall is much less fault tolerant that Agile is.  Even if you design
 > the perfect software program to suit the initial requirements, by the
 > time you're done, it's almost guaranteed to no longer be what's needed,
 > even if the initial design ever *was* what the user needed 8 months ago.
 >
 >> > "competent" people will do a competent job, and incompetent people 
will
 >> > do an incompetent job. "Agile" does nothing to improve this truism. It
 > But it *can* mitigate its effects.  When you have to show your work
 > frequently, it becomes very obvious who is not holding their own.  It
 > also means if someone does muck things up, you've lost a few weeks
 > instead of a few months.  If you're pair programming (which I am a big
 > fan of), you may be able to compensate with proper pairing.
This is the cudgel I was talking about. Great engineers with hard 
problems look worse than horrible programmers with easy tasks. This 
combined with a management that has the view that engineering needs to 
be "controlled." Creates a very stressful environment.

If seen it happen numerous times, dunderheads become "stars" and clever 
people who actually create functionality or solve the problems get shit. 
Worse yet, the dunderheads look like even bigger stars, because they 
"fix" their bugs (which if they did it right the first time and had been 
late, wouldn't be there) faster.

 >
 >> > only makes the development process short sighted and puts the team 
on an
 >> > endless treadmill of unobtainable "sprints."
 > The developers are right there in the sprint planning meetings, daily
 > standups, and sprint retrospectives.  If the plan for the sprint is
 > unobtainable, the developers are just as much to blame.  If the
 > developers aren't thusly empowered, then it's not Agile.
That assumes "management" are reasonable.
 >
 > Part of the process [in most flavors of Agile] is tracking velocity (how
 > many story points can be completed in a sprint) and how big a story
 > point should be (based on estimated vs actual).
That assumes "management" are reasonable.

 >> > Agile becomes a cudgel for management to have developers ALWAYS behind
 >> > the 8-ball because things always take longer than estimates. Agile's
 > Agile doesn't dictate how long things should take; you and your
 > coworkers do.  Even if you have two-week iterations, that doesn't mean
 > every piece of functionality has to be developed in two weeks.
 >
 > One aspect of [most forms of] Agile is a balance of power  (the
 > following is an oversimplification and generalization):
 > - The PO (Product Owner) comes up with the stories (requirements).
 > - The PO and the developers discuss implementations and acceptance
 > criteria.
 > - The developers break stories up into tasks and assign story points
 > (time estimates).
 > - The PO, armed with this data, decides what stories should be in the
 > next sprint, subject to the story points adding up to less than the
 > length of the sprint plus testing time, etc.
 > - Everyone meets regularly so if things are going off-track, measures
 > can be taken to compensate (dropping stories from the sprint,
 > redeploying resources, etc).
 >
 > You see, the *developers* say how long things should take, and the PO
 > says what gets worked on and when.  Balance of power.  The PO can only
 > put one sprint's worth of work *based on the developer's estimates* in
 > the sprint.
  In an ideal world this may work like advertised, but corporate 
entities where marketing, sales, and corporate executives are basically 
self serving sociopaths, there is no protection from abuse. Poorly 
written or incomplete stories put developers at risk because you see an 
"easy" problem to solve, and then during testing the PO says this isn't 
what we discussed.  You show the documentation and what is "obvious" to 
one is not "obvious" to another. Since, corporately and politically the 
"PO" is higher ranking than the developer, the developer is said to have 
screwed up.

You can't eliminate the politics or crap, and the worse the politics is 
in a company is, the worse agile gets.
 >
 >> > time constraints forces a reduction in problem analysis which means
 >> > that
 > Not reduction; deconstruction into manageable testable chunks, and not
 > working on things you don't need yet, because you may never need them.
There are problem domains that are not trivially solvable, and worse 
yet, appear simpler at the beginning. Agile does not work well with 
this. Especially with insane management that looks at the sprints and 
sells the products before they are developed.

 >> > you don't really understand non-trivial problems until you are already
 >> > late. Before you know it, you're at work at 9:00 PM working feverishly
 >> > to complete a feature before the next day's stand up.
 >> > In several companies I have worked at or with in the last few years, I
 >> > see the same thing. The old adage is more true under "Agile" than ever
 >> > before: "There never time to do it right, but there's always time 
to do
 >> > it again."
 > I have never faced a situation in my current company or my last where I
 > was told to opt for the quick fix instead of redoing it right.
 > Shortsighted bad management is shortsighted bad management no matter
 > what process you claim to follow.
Yes, and agile puts short sighted and bad management closer to the 
developers.
 >
 >> > Then, don't get me started on CEOs and MBA types that preach 
"Agile" to
 >> > "get engineering under control." Kiss that 50 hour week goodbye. You
 >> > might as well change your designation from "human" to "veal," because
 >> > you are sitting in a small box for the foreseeable future.
 > You can fill in almost any process (Six Sigma, ISO-900X, TQM, waterfall)
 > for Agile in that sentence.  Managers want a silver bullet and are
 > unwilling to accept that TANSTAAFL.  As with all of these processes,
 > there are pundits who hawk it who don't understand it themselves, or
 > knowingly misrepresent it for their own gain.  That has nothing to do
 > with whether Agile is good or bad.
Well, this is a little disingenuous. Agile makes it easier for bad 
managers to be worse because it removes a level of isolation. Yes bad 
managers are bad, bad CEOs are bad, bad marketing and product management 
guys are bad. BUT! There are many more "bad" examples than good ones. If 
your process does not try to address these issues, then it is no better 
than any other process. If, in fact, it removes protections and 
isolation, then it makes it worse.


I think in the end, we disagree because I have seen first hand and 
through colleagues the burn out, the stress, the bad management, etc, 
with agile.