Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday July 28, 2006
11:29 AM

A "must read" for XP lovers and haters

[ #30462 ]

You must read this paper by Alistair Cockburn. It's about his experiences with decades of managing and studying projects. It all seems to boil down to variations on a theme. People not doing the work come up with Ways Things Should be Done. People actually doing the work ignore the Ways but get their work done anyway. To make matters worse, he write "I have not yet interviewed a successful project that had accurate documentation, unless either the code or the documentation was generated automatically."

He cites plenty of anecdotes of systems being created to help people do their work, but the people perversely ignore those systems. People don't want to read a project plan, they want face time. People don't like someone coming in and telling them how to change all of their work habits when those same people knew they were already getting work done.

I think what we can gain from his observations is what many of us know in our guts: people can get stuff done regardless of the environment you put them in. Don't tell them how to run an obstacle course. Just let 'em run the damn course. Sometimes my coworkers get irritated when I just walk up to talk with them, but I get irritated when, after five emails, we still find out that someone misunderstood what happened.

Give 'em face time. Take away obstacles. Don't tell 'em they need to fill out reams of documentation. Figure out how to strip away bureaucracy. Give them end users to talk to, not just email. And most importantly, trust them. If you can trust their technical decisions, they're more likely to trust your business decisions.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Reminds me of The Importance of Fudgability []. Choice quote:

    Part of the problem was how arrogant we were. We believed that we could spend a couple of days watching trained lawyers perform a highly-skilled job, talk briefly to them, and then make their jobs completely obsolete.

    • This is a good article too.

      I liked the part about an inability to recognize the issue of fudgeability:

            Software written for life-critical systems may
            need 100% solutions - but this is rarely true
            for general business systems. Software
            programmers will rarely tell you this, because
            they live in a world of edge-cases and
            perfection and can't bear to write a system
  • This particularly caught my attention:

    A willingness on the part of team members to address any and all project issues has proven invaluable on many occasion...

    Both of the times I decided that I didn't like where I was working any more and quit was when I hit resistance to fixing issues that were obviously broken: the implementation was obviously not what the users wanted, but software a manager had been carrying around on tape from an old job, so That Is What We Will Use; the other was simply a project that

  • It is a good article. I wonder if it will have any effect.

    One thing I took away was the power of working face-to-face. I guess that explains the importance of conferences and hackathons over Internet activity like here in the use.perl journals.

    Then again, what I write here, I might not be prepared to say to anyone face to face.
    • Indeed, I think the hackathons are important, so important that it's the primary reason I flew over to YAPC::NA this year. I did hardly any actual talking during the whole time there, but I spent enough time talking to resolve half a dozen major blocking points, unconfuse a few confused situations, and generate enough new clearly structured Things To Do for about half a year.

      Well, that and I REALLY needed a holiday :)
  • Thanks for posting this link, much appreciated. It puts in somewhat more formal language a lot of the features we look for in a team but can be difficult to specify. And many times management looks for some of these beneficial effects without giving up the control and predictability they think they have.

    That this is someone who has looked at many different types of projects projects of many sizes over many years makes it even more powerful. (That is, it's not just the 37signals folks preaching to the choir

  • How the hell have I managed to miss that!

    Damn... and I was planning to do something useful this weekend rather than fritter it away following random links.
  • This is ironic. What is fixed in their behavior they can't do anything about.

    What is inconsistent (but should be consistent) they also cannot do anything about.

    I was surprised today someone believing the air conditioner was now working because they felt cooler. In fact, it wasn't working at all.

    But I realized I make mistakes like this all the time with my coding. I think I have fixed a problem, but it is an illusion. What is it about looking at symbols on a page which make it harder to prevent these misconc