George Dinwiddie’s blog

Esther Schindler quoted me in her article, Getting Clueful: 7 Things CIOs Should Know About Agile Development, on CIO.com. Unfortunately, my advice got altered a little in the editing process. She says,

Consultant George Dinwiddie from iDIA Computing suggests using a burn-down chart to track project progress.

I actually recommend a burn-up chart to track project progress, and a burn-down chart to track iteration progress.  There are specific reasons that I think a burn-up chart is superior to a burn-down for tracking over the course of a project or release. I’ve been meaning to write a long post about this, but haven’t found the time. I just wanted to correct the record, in the mean time.

The full comments of my note to Esther: (Continued)

I know this has been bandied about hither and yon by lots of people. But I still see statements like the one by James Bach quoted on Matt Heusser’s blog that “the part of the testing problem they address is a small fraction of the whole.” Well, yes. Of course it is.

Maybe that’s because Test-Driven Development (TDD) isn’t a testing technique. It’s a software development technique that happens to create a safety net of unit tests.

Or, to paraphrase Captain Jack Sparrow, (Continued)

Some of you may remember that I started a house construction project. Things are moving very fast, now, and the actual construction may take less time than it took to get all the necessary permits. So far, the project’s about 100% over the time budget. And people say that software development should be more like the construction industry!

But the fact that the construction has run slower than expected is not the reason for this post. Neither is the fact that this project has been consuming a large portion of my attention, and hindering posts on this blog.

This post is about an example of refactoring found in the house construction domain. (Continued)

Do you have a hard time keeping track of those articles that you read and think “I could have used this when I was talking to ….?” Do you sometimes need an article to back up a point that you’re making, but don’t know where the data is? Well, I do. I’ve started lists a number of times, and keep misplacing them.

This time is different. When a discussion on one of the mailing lists got into studies demonstrating the effectiveness of Agile Software Development, I decided to start a list in a place that won’t get lost. That place is http://biblio.gdinwiddie.com/, the Agile Bibliography Wiki.

I’d really appreciate it if you’d use it too.

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)

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)

What’s in a name?

I happened across Debasish Ghosh’s post “Inject Repositories, not DAOs in Domain Entities” and it triggered a few thoughts. In this post, he suggests that the Data Access Objects that perform database reads and writes should be wrapped in a Repository wrapper to isolate the domain layer from the details of the persistence layer. What do I think? Well, yes and no. Let’s look at this in a little more detail. (Continued)

Dave Smith wrote about his new camera, justified on the basis of recording whiteboards after meetings, triggered this post. In his post, he states,

“The one problem is the flash, which tends to white out an area of the whiteboard, requiring either multiple shots or shooting off-center, which leads to odd looking results.”

(Continued)