

Agile/XP Critique: It's not the Code, Stupid - DanielBMarkham
http://www.whattofix.com/blog/archives/2007/12/its_not_the_cod.php

======
tx
Any kind of "methodology" is aimed at improving the predictability of results
expected from a group of average coders. Thus it's no surprise that "large
client" appears in the first paragraph of his blog post.

In reality, software engineering is more like an art, and each project calls
for a somewhat unique approach, unique style. There is a lot to be said about
general sense of style and beauty when it comes to programming. Imagine
Leonardo "going Agile" on Mona Lisa in order to speed up the process.

Of course there are always armies of copycat CRUD projects that have nothing
unique about them. It only proves my point of average quality of "agile
programmers" because good engineers aren't interested in CRUD work. Ruby-on-
Rails is an awesome example of this: one good programmer did all necessary
thinking for you.

It is perfectly possible to deliver a "typical Rails" site without even caring
for learning Ruby. A good methodology done right allows code monkeys with
surprisingly low skill level to be productive (which is, of course, not a bad
thing). Rails is agile-carved-in-stone approach that forces you to stay on
track and punishes from levitating from it, I guess this is where word "rails"
comes from.

This drives many MBAs nuts: none of those dog-training managerial books filled
with pompous common sense seem to work when applied to software: good
programmers simply don't respond to "positive reinforcement" and average
programmers produce average results no matter what. All those "methodologies"
allow managers to get average results _reliably_ regardless of quality of
talent at their disposal.

~~~
DanielBMarkham
Thanks tx. I guess there is a cost-reward factor at work. I know RoR and the
various automated DAL guys are really happy with working inside a narrow, but
fully fleshed-out paradigm.

------
DanielBMarkham
Interested in any comments about this article -- I thought about submitting it
to a client who is really gung-ho on XP and Agile, but I'm not sure if I'm
making any sense or if it would tick them off. Feedback appreciated.

~~~
projectileboy
I more or less liked it, but I was sort of confused by the sell... I do a lot
of gigs where I play an agile-shmagile "coach", and much of what you wrote
sounds to me like you're in violent agreement with the rational portion of the
"agile" community.

~~~
DanielBMarkham
What I'm seeing is people dropping one onerous system -- say traditional
waterfall -- and creating a new onerous system built around favorite authors
and books. I think people get the "feeling" of agile but miss out on really
how it is supposed to work. I mean, I'm seeing customers quoting books back
and forth to each other -- even calling in famous authors to make decisions on
what they should be doing. Famous authors, bless their hearts, don't know jack
squat about any particular team or project and shouldn't be making blanket
announcements about what teams "ought" to do. That's the same stuff they're
trying to get away from. There are no perfect answers.

I come from the rational side of agile as well. This is the first time I've
seen so many people so excited about giving teams freedom that they're
prepared to spell out exactly what those teams should do in order to be free.
If you only concentrate on delivering code you miss the other value you add.
Teams can't run on manifestos and slogans.

~~~
projectileboy
Yeah, the whole cult around some of those authors is laughable; reminds of the
Gilderoy Lockehart character from Harry Potter - those who can't do, write -
and "teach".

I did like the XP books by Kent Beck, though, because I thought they captured
what for me is the most important aspect: you start with a simple process that
seems reasonable, based in the values that are important to your organization.
And then you adapt the process as you move along, without worrying about what
some dude in a book said to do.

~~~
DanielBMarkham
I think these guys have their heart in the right place, no doubt. I think what
I see that is missing is organizational agility. There is a lot of
organizational risk that just goes unanswered, and once the questions begin,
these guys start sounding awful prescriptive. It's almost like they expect
large organizations to run completely from a focus of one team, and one
developer, instead of the entire structure. That might sell a lot of books to
frustrated programmers on teams, but it kind of side-steps the whole issue of
"how do we pick what to use or not use in a dynamic fashion? How dynamic can
an organization be, anyway? Could you deploy to production different ways for
different teams? Should project chartering be done with information that is
also valuable to the team, like a business model? If you have running code and
not enough people know what you are doing, do you stamp your feet and keep
saying "integrated team of generalists" or do you acknowledge the fact that
written communication is the only way your are going to reach some very
important people?, etc." I don't see a lot of that type of thinking going on.

I too do the coach thing, usually for big organizations. I also do the startup
thing (which I love) with small teams. Care to guess which one I like more?
(grin)

