I guess I’m just slow.
Somehow, in eleven years and a hundred or so efforts teaching, coaching, and doing extreme programming (XP), there’s all this stuff I haven’t learned.
Impossible Means Can’t Be Done
I’ve heard more usage of the word impossible than you could readily imagine. It’s impossible to release more frequently, adequately test w/o the shipping binary, get a database on everyone’s desktop, make a build that works in under a minute 90% of the time, on and on and on.
Turns out, at least in my experience, impossible really just means we’ve never tried that. I can fix we’ve never tried that.
XP Requires High-Skill Teams
This noxious notion burbles around the interwebs in various configurations, as it has since the beginning of XP. It’s mistaken.
I’ve worked with many more low-skill teams than high-skill ones, for two reasons:
- I’m not cheap, therefore much of mybusiness comes from teams that are in trouble. High-skill teams can hide and defer trouble far longer than low-skill ones.
- There are far too few programmers, therefore the world of commerce has to settle for low-skill (and no-skill) ones. At least 75% of all programmers are low-skill ones.
I keep thinking I should give up before I start when I see a low-skill team. Fortunately, I am really bad at money, so I don’t refuse many clients. This has impressed upon me the complete irrelevance of skill level in adopting and adapting XP.
Internal Quality Trades For Productivity
This is one I really wish would go away.
Sadly, many ass-clown psuedo-coaches continue to stress it. (For a more reasoned response, go here. I just don’t feel like sugarcoating today.)
Look, kids, if you think this one’s true, you are falling for the lump-of-coding fallacy, which I’ll write up real soon and back-link to.
To raise productivity, start by attacking friction with some internal quality.
Incremental Methods Make Bad Designs
This one is so hard for folks because the concern seems legitimate in theory. If you just design for today, doesn’t it seem true that tomorrow you’ll have a bad, i.e. suboptimal, design? Trivially yes.
But there’s a hole in this: people tend to think suboptimal design is whatever really awful piece of post-digestive effluent they saw when they worked for a company that has no method. They’ve experienced the horror of adding functionality to a piece of code that was not designed at all.
When tomorrow becomes today, yesterday’s good design is readily updated to become today’s.
Brand-Name Methodology Matters
Confession: I invested a lot of time, energy, money, and stress in trying to make Extreme Programming a brand. In particular, I worried about the word ‘extreme’ and how it would affect sales, and I worried about judging who was or wasn’t in the special club.
I have now seen IBM, Microsoft, and HP all claim some or all of the ‘agile’ brand. Give me a fucking break, yo.
A method based on helping individuals interact is never going to make a real brand.
What about you?
unlearned lessons to share with us?
Add a comment or drop me e-mail.
Next-Up: Who knows? I’m in a mood.