Wednesday, June 16, 2010

More hardlining

Matt Heusser says

If your company is just starting to talk about "agiling up" it's software process, my advice is to forget about timeboxed iterations and test driven development. Oh yes, those are good things, and they can enable agile software development, but let's be very clear:  if the team isn't self-directed, cross-functional and respecting of its people, it's not Agile software development. It's ... something else.

Hold on to those ideals. Communicate about them clearly. Fight for them, leave no room for misunderstanding, and you might just make your little part of the software development world a better place.
I think that is noble, and worth fighting for.

Read the whole thing by Matt Heusser.

Monday, June 14, 2010


I wrote the following toward the end of my last contract.  I hesitated to post it because I didn't want to offend the folks I worked with, and because I worried about the effect it might have on my own marketing.  With some distance now, it doesn't seem that offensive,  and if it eliminates some potential opportunities, they're likely to be in places I wouldn't want to spend 40 hours a week in anyway.

My current "engagement" has turned me into a hard liner. I was burned, and I saw the light. I'm not going to go into details, because I don't want to be blacklisted as a troublemaker.

But I suspect I have no choice: I am a troublemaker.

I'm a true believer, and what I believe is this:

There is no Agile but XP and success is its profit.

Anything else that calls itself Agile is just a compromise with an increasingly myopic business/bureaucratic culture obsessed with short-term profit and the illusion of control and predictability via hierarchy.

Scrum may rein in some of the worst tendencies of that culture, but it doesn't get at the heart of the problem.

XP is about two things: one is communication - the dynamic perfection of process.

The other is perfect software.

This is not the static Baudelairean perfection of BDUF.  It's dynamic, minimalist, infinitely flexible.  To be an XP developer is to be a Zen calligrapher inscribing sacred language, to apply all one's intellect and energy to creating and maintaining software that does exactly what the stories say, no more, no less.

XP originated in the context of OO.  Unlike relational databases,  OO didn't spring full-blown from simple, elegant mathematical models, but it has evolved into something damn close.

This vocation is absolutely incompatible with the hierarchical/centralized model in which coders have no autonomy.

The bureaucratic model runs on the differential presence of one human emotion: guilt.  You rise to the top of a bureaucracy by becoming (or being born) a sociopath,   pushing risk downward.  Those stuck at the bottom accept this burden because they are guilty. The vision of future reward,  through graduation to heaven,  winning the lottery, or the application of sheer pluck and grit, is a consolation, not a motivating force.

I've been there - recently - I know exactly how that guilt works. People who work in the environment I'm talking about  would recognize the power of that guilt - if not for the protective psychological repressions and distractions - the bread and circuses - that make it bearable.

XP flourishes in startups and small businesses that can't afford IT departments.

But I want to take it into the belly of the beast.  XP is strong medicine, tough love.

Part II - Heroism

Waitaminit!  The success of TradDev [i.e.  waterfall/hierarachy/cmd&ctl] is not all about fear.  There's a carrot, not just a stick.  It's the solitary pleasure of heroism.   And the dark side of that is empire building and job-security-thru-opacity.

I had a heroism moment of my own:  successfully refactored some legacy Flex code without a net - i.e., no tests.  That was scary, and given the pathological coupling of the undocumented/untested codebase, it could have been a disaster.  (Actually, it still could be.  While I'm on that subject, instead of working effectively with legacy code by building a test harness around it, the team is drawing diagrams to document it. This will just contribute to its rigidity.)
As I write this, two heroes are talking near my desk.  It's a happy conversation. They're reinforcing each other's sense of being on top of things, and the buzz of working without a net in a risky environment. So what if it's about BDUF?
Now I'm idle.  No corkboard with cards for this iteration waiting to be picked up,  no pairing.  Waiting to get a JIRA (i.e., a task) assigned to me by our manager, who's working from home.  Yet another example of waste in the TradDev world.  I'm here waiting, so I'll bill for it, but it feels nasty.  If I offered to go home, what would happen?