George Dinwiddie’s blog

This week, Chris Matts tweeted, “Contemplating whether GIVEN-WHEN-THEN is back to front. The system should do <outcome> WHEN <event> PROVIDED <stimulus context>… Hmmm.” Let’s try an example. “Given I have $500 in my account, when I withdraw $50 then I have $450 in my account” becomes “The system should show $450 in my account when I withdraw $50 provided I had $500 in my account before.” It doesn’t exactly roll off the tongue, does it? Putting the result first makes the sentence both more complex and more passive. Yet I can understand the impulse that triggered this tweet. (Continued)

Documentation! It’s what we do.

People approaching Agile software development for the first time often ask about what documents are required.  When I ask developers what annoys them most about other peoples’ code, I frequently get the answer that it’s not documented well.  And I can’t tell you how many times I’ve heard people express the opinion that Agile software development is undisciplined because you “don’t do any documentation.”

Why is documentation so important to us? (Continued)

There were a couple dozen people who showed up at the Fool, last night, for my presentation on A ”Lingua Franca” to Ensure You Get the Right System.  I’d like to thank them all for coming and for such lively participation.

These are exciting times.  The tools of acceptance testing and behavior-driven development are progressing beyond the domain of the techies.  They are entering the realm where they can help the Whole Team. (Continued)

A few weeks back, in a conversation with a colleague, I raised some issues that were important to me.  Well, I tried to raise them.

“Don’t worry about that.  Besides, I’m working on these other issues that are more important.”

That response reassured me–NOT! (Continued)

I applied for a new credit card. I wasn’t in the market for a new credit card. I shred credit card offers almost daily. No one sent me an offer that I found too irresistible. No, the funny thing is that my current credit card bank spent money and went to a lot of trouble to convince me to open an account somewhere else.

It sounds very odd, doesn’t it?

Now I happen to know that this particular bank has worked to embrace Agile software development. I know people who have worked with them to do so. And I’m sure that, considering the size of the organization, they’ve made great strides in improving their software development practice. Yet the events that transpired today tell me that they’re missing an important feedback loop–arguably THE important feedback loop–the one that involves the customer.

Here’s what happened: (Continued)

A while back, I was working with a young and cocky software developer. He was a smart guy, and sure of his abilities. He had seven years of Java experience, he said, and he knew how to write code.

As he was a new member of the team, I described the strategy I’d planned for a bit of code. I showed him what I’d already written, and asked him to complete the functionality.

“But I can do it another way.” And he described a different technique. (Continued)

So much of life, even so much of software development, comes down to interaction with other people. And a big key (perhaps the big key) to this is building relationships. David Maister says some very interesting things on this topic–things that hit home with me. I’ve been meaning, for some time, to comment on an interview he gave on another site. While I’m waiting to get around to that, let me point you to this wonderful podcast (available in audio and video formats). Go watch it; I’ll wait. (Continued)

There’s been some discussion on the XP Yahoogroup about the practice of “blocking” in order to protect an Agile team in a non-agile corporation. I’d gotten rather behind in my reading, and came into the middle of the discussion. I’ve just now tracked this discussion back to a post by Scott Ambler, where he says,

This is a great example of something that I call blocking, where you produce the paperwork, attend the meetings, pretend to care, … to make it look as if you’re following the “official process”.

Scott is responding to a mention of the use of PERT on the Polaris submarine project. Scuttlebutt says that PERT was deemed a great success in managing the Polaris project, but in reality the PERT charts were reverse-engineered from more seat-of-the-pants management techniques. As the stories go, this “scientific” management technique wowed the Congressional oversight committees, and such techniques have been the backbone of government contracting oversight ever since. (Continued)

Jerry Weinberg said this a couple days ago (and probably many times before that, but that’s when I heard it). Today, I have a story to illustrate this. I also have a puzzle to solve about how I may best avoid this same trap. (Continued)

Ron Jeffries, when someone asks for data to “prove” that XP or some development practice works, is wont to say that the person they’re trying to convince may be asking for evidence, but it’s not likely that the evidence will convince them. (Continued)