George Dinwiddie’s blog

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)

There’s a thread on the Extremeprogramming yahoogroup attempting to define Agile. John Roth started this thread with a trial balloon of ways to recognize an Agile project from easily observed practices. I have a bit of difficulty with this definition; I think that it’s too prescriptive and, while it could be a useful heuristic, would miss the mark in numerous cases. To my mind, it doesn’t zero in on the heart of Agile practice.

So what is the heart of Agile practice? In the ensuing discussion, Dale Emery posts a message the turns attention to feedback.

The whole team focuses intensely on producing accurate, relevant, timely feedback about product, project, and process.

I’ve written about the importance of feedback, before. Using feedback is not the defining aspect of Agile, of course. Using feedback is the basic mechanism for any control system. (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)

I was reading Jerry Weinberg’s book, Quality Software Management: Vol. 2, First-Order Measurement, and came across the following:

Software’s nature is to be invisible, unless we work to make it visible…. During a construction project, we can see the building rising; but during a software project, all we may be able to see is a programmer staring at a screen.

This got me to thinking, as Jerry’s writing generally does. (Continued)

… and fruit flies like a banana. It’s amazing to me that it’s been three weeks since my last post. Sometimes real life has a way of consuming the time, leaving little left for philosophizing.

During this time, Brian Marick has been stirring things up at the Agile Alliance. I’ve joined in the discussion of his observations and proposals only a little. Brian’s turned over a lot of stones at once, and it takes me awhile to examine all the things that have been living under them. Being a Myers-Briggs introvert, I tend to discuss these things in my own head before displaying them to the world. Here, though, I’m just thinking out loud and I haven’t come to any conclusion. (Continued)

Recently, I wrote about using the JfcUnit and Abbot frameworks to test-drive the creation of a Java Swing GUI. Since then, a post by Liz Keogh on the ExtremeProgramming yahoogroup led me to another option. It a wrapper around Swing written in conjunction with JBehave, but as Liz points out, it’s not dependent on the framework and can happily be used with JUnit, also. I like the fact that it’s really lightweight and fast. (Continued)

Dale Emery wrote a wonderful post about the Prime Directive on the ExtremeProgramming yahoogroup. This blog entry is mostly to prevent me from losing track of Dale’s comments, as is easy to do on a busy mailing list. I want to be able to go back and re-read his words. (Continued)

It’s been awhile since I’ve written any Java Swing code, and doing so now is making me feel a little stupid. Test Driving the development of Swing hasn’t improved much since the last time I did this.

Back in 2003, Jeff Waltzer and I decided to experiment with TDDing a Swing application to see if GUIs could be test-driven. It wasn’t always easy, but we convinced ourselves that they could. We started out rolling our own Swing test framework, but soon found ourselves immersed in AWT threading issues and Swing peculiarities. So, since we seemed to be headed down the road of reimplementing JfcUnit, we decided to switch and use the real thing. (Continued)

Johanna Rothman’s recent post on the AYE Conference prompted this unsolicited testimonial.

If you’re a techie working with people, you can learn loads about being more effective by attending this conference.  This is no sit-in-a-room-and-listen sort of thing.  You’ll get involved and learn lessons you’ll never forget.

I’m an independent consultant and pay for my own training.  This conference is one I won’t skip.  It’s well worth the cost.