A few things are serendipitously coming together for me at the moment.
Just watched this video where James Randi debunks Uri Geller:
Recently read Richard Feynman's 1974 commencement speech at Caltech.
Ron Jeffries just posted Issac Guoy's questioning of the evidence presented in Craig Larman's Agile and Iterative Development: A Manager's Guide.
Cedric Beust recently blogged about how Agile people still don't get it.
James Bach blogged about defining agile vs Agile a while back.
What I'm thinking is that sloppy thinking and pseudo-scientific justifications for believing and doing things is not what I want to be doing. I'm also thinking that "Agile" most likely doesn't mean to you what it means to me so it's not very useful to use "Agile". Finally, inspired by Don Norman, I don't really want to talk about the "agile community" vs the "Agile community", or "Agilists" vs "the others". "Agile" isn't real. The "Agile community" isn't real. People are real. Community is real. I'd rather think and talk about that.
Yahoo!7 Girl Geek Dinner Pictures & Screencast
-
Above are some pictures from the Girl Geek Dinner night at Yahoo!7 If you
have photos on flickr please add them to the pool too. Pool/Group ID
1173495@...
3 weeks ago
8 comments:
Nice post. I like it. Maybe one day once the Agile and other process hype dies down, this will be how we talk about software development.
-Jonathan
great sources, mate, some of the better thought provoking stuff I've read in a while
Jonathan, there will always be hype about one thing or another. No sense waiting for it to die down. Why not start talking about software development in practical terms right now?
Jason, I just went back and read the Feynman piece you linked. I began to wonder, if all it really took to debunk witch doctors was simply to observe that their methods didn't actually work, how it can be that so many putatively intelligent people continue to defend traditional software development methods in the face of their appalling track record?
I suspect this is not exactly the same impression as you received from the piece. From your other comments, it seems as if you were wondering how so many putatively intelligent people could believe in "agile" development methods in the face of...well, in the face of tradition, I guess.
Have we been reduced to picking our favorite witch doctor and sticking with him no matter what?
More importantly, why is it that beautiful nude women so rarely intrude on our meditations about software development methods? Seems like it hardly ever happens!
Hi Dave,
My point is that even if we have something we believe works better, it is yet still important that we are scientific about it. It is simply not good enough that we might happen to be correct if the way we approach it means that our correctness is really accidental.
I agree with that, although I also note your quote in a recent post about science and engineering.
The need to understand why things work or why they don't work is the reason I've been taking an interest recently in nailing down the business value that particular agile/lean practices actually deliver. I "know" from experience that the approach is sound, but we have entered a time in the industry when we have to be able to quantify the value and deal effectively with implementation problems in order to succeed on a large scale and in a sustainable way. Circular debates about the scope of a unit test vs an integration test won't take us there, even if that's a good discussion to have on another level.
I guess you could say I know how to build a brick wall, and now I want to be able to explain how cement works; specifically, explain it to the people who are paying for the wall, and not (necessarily) to the bricklayers.
It sort of clogs up the bandwidth when people (as in the thread on Cedric's blog that you linked) simply mis-state the basics and go off on a tear based on some assumption or misconception they have. My knee-jerk reaction to that is to try and address the misconception directly and do some myth-busting, but I wonder if that's really useful. There will always be those who resist change just because it's "change" and not because they have bona fide concerns about the proposed change that they can articulate in an objective way.
How much time should we spend with them? It's hard to say. It's probably worthwhile to spend some time with them, since they will benefit along with the rest of us if they can calm down a bit and consider things objectively. But there's a point of diminishing returns in doing that. The audience we need to be focused on today are the so-called "early majority adopters", based on the conventional technology adoption curve. That's a business constituency, and not a cadre of traditionally-minded programmers, so it's a different argument at a different level of abstraction. That brings us back around to my current preoccupation with delivering "value", by which I literally mean financial value as opposed to "soft" values like "making the code easier to maintain" and so forth.
Sometimes addressing misconception is more for your own understanding than the other person.
I'm not so much talking about different audiences per se. It's more that if we talk about financial value or maintenance effort, whatever, we should not be vague and loose with our reasoning.
Two excellent points. The first I will take as constructive criticism or at least as sound general advice. The second I agree with. I think looking for ways to quantify the hard value of certain practices is a way of tightening up the reasoning. Otherwise, a lot of these discussions only amount to circular debates about personal preferences.
Post a Comment