The Google Web Toolkit was presented at last nights Twin Cities Java User Group and I have to say it seems like a very impressive framework. It basically abstracts the entire UI (HTML, JavaScript, CSS) into your Java code. It also AJAX-enables the application using a proprietary binary remoting protocol. Google’s tagline for the toolkit is that it “is a Java software development framework that makes writing AJAX applications like Google Maps and Gmail easy for developers who don’t speak browser quirks as a second language.”

Although it does seem like a very well thought out framework, I don’t think I’d want to use it for many applications. Because the UI is in Java code, you end up with a ton of code for setting up your layout. You could argue that since you don’t have HTML, JavaScript, and CSS files to worry about, the increase in code size is justified, but I don’t really think that’s true. You can hire a different caliber of developer to do those things, so with the GWT, you end up having to pay a Java developer to do things that a less expensive resource could have done. In addition, a simple UI change could end up being very costly and time consuming because it involves a lot more than just tweaking an HTML or CSS file.

For a developer who doesn’t know web UI very well or is experienced with Swing-type layouts this could be a great solution, but if you’re on a team with designers and front-end developers, it doesn’t seem like a great fit. It might be a better fit if you were developing an application like Google Maps where the layout is very simple (if repetitive) and it needs to incorporate a lot of AJAX functionality.

GWT is definitely cool and I plan on watching where Google can take it in the future.

In Construction Metaphor: Collaboration over Contracts Steve Berczuk speaks to his recent experiences with a home renovation project and the parallels it has with managing software projects using agile values.

During the past year my wife and I decided to basically gut our 1890s era house, undoing a poor addition that had been done in the 1950s, reconfiguring the existing space and adding a room. During the initial phases things seemed to be moving along. We had plans drawn up by an architect who understood our needs at a high level, and the general contractor made visible progress. It was towards the end of project that things got frustrating. Things weren’t happening as we expected. We fell out of the rhythm of weekly meetings. I felt out of the loop about some things and what started out as a team of Architect, Homeowner and Contractor moving towards a goal started to feel like a circle of blame, where everyone was upset at each other.

I thought about this a bit and realized that what was missing from the building experience was the main thing that makes agile software projects successful: feedback. I would have been happy if I knew at the start of each week what would and would not get done. That we would be making progress, and that the progress would focus on my priorities would have been as good as everything being done on schedule. If we had had daily scrums that would have gone a long way towards keeping the project moving, but that was too much of a culture change introduce!

I concur! If I had been able to meet daily with the foreman of each group (or the whole team) of subcontractors building my house a couple years back things would have gone a lot better. Contractors are just like everybody else and will continue to do what they are doing unless pointed in a different direction. Had there been the daily oversight that scrum brings, I think we could have avoided many delays and misunderstandings about what was to be built.

I was actually quite surprised at how much of building a home is figuring stuff out as you go along. I would not have been as frustrated by this if I was able to apply a couple more agile principles to the tasks.

I echo Steve’s sentiments that agile values like Customer Collaboration over Contract Negotiation as a means to build better houses and share in his consternation that this is such a hard sell at the outset of many software development projects.

See also: Scott’s post of Alastair Cockburn’s agile house renovations

Here’s a nice round-up of the major processes and methodologies out there. I’m sure the list isn’t complete, but most of the major ones are touched on. It’s a nice reference because it’s short and sweet.

The author doesn’t specifically endorse any of them over the others, but I’ll go ahead and share my favorites in the Best Practices category (hopefully it’s obvious at this point that we endorse Agile processes and methodologies):

• DRY (Don’t Repeat Yourself) - I’m always amazed at how an implementation can be flushed out to a nice design when you keep this in mind. When you force yourself to refactor out duplication, you often end up with a far superior design as a nice side effect. I tend to use the “Rule of 3″ with this; the third time I’m about to duplicate something, I try to refactor out the duplication. I find that trying to absolutely eliminate duplication can cost more time than it’s worth. See Refactoring to Patterns as well.
• TDD (Test Driven Development) - I don’t have as much experience with this as I’d like, but even a taste of it has shown me that there is merit here. It can be a difficult mind-hurdle at first, but testing first has many benefits. You get increased test coverage (duh!), a fast feedback mechanism on what you’re doing, a simple place to start a complex problem, an organic design, etc.
• YAGNI (You Ain’t Gonna Need It) - Trying to predict the future, especially in software development, rarely works out well. Just accept up front that you don’t need to worry about all the what if’s and life can be so much nicer. Not writing code is probably one of my favorite activities after removing unnecessary code. :)

Well, those are three of my faves; feel free to add any others that you like to the comments.