I’ll be launching a small project soon to remove the last dependency on a certain unnamed enterprise tool my company purchased years ago for a few hundred thousand dollars. It has the cost benefit analysis every business person could love. For a week or two of one developers time we can save 50k a year on the support contract. It’s rare when things are that clear cut. And it reinforces a lesson I’ve learned over and over never to promise the business some magic from an expensive tool.

I started my first ever iterative project with a very complete exhaustive requirements iteration, then a design and prototying iteration, and then three iterations where we delivered code, then a system test iteration, and finally a deployment iteration. Booyah! My first iterative project!

At the end I looked back and felt pretty much like other projects I’d run in the past. I had read up on RUP, but misapplied it badly because I made what is apparently a fairly common mistake. Basically it runs RUP as a waterfall. A lot of this was because I didn’t have the advantage of actually being on a well run iterative project. I’d been part of a team or even run several projects, but I was always one of the few who knew anything about methodology. A lot of this harkens back to dotcom days when even knowing about a basic software development lifecycle was something to toss on the old resume.

The funny part was the project was successful for the most part, basically because of the people on the project who did what was needed to get the job done. People very often can trump pretty bad processes.

Anyway I find myself in a similar position now implementing Scrum. I have no examples to go by so my information is again from books, conference presentations, and blogs. Still Scrum is a pretty straightforward process, but all sorts of things can still crop up and the implementation details can kill you. One of these days it would be really, really nice to have a mentor who knew a lot more than I did. Still showing any attention to Agile methodologies is still pretty bleeding edge for most corporate IT shops, so it’s hard to find a mentor unless you can manage to hire one in.

It occurred to me that if JSF is starting to see a lot of adoption, that there’s probably some testing framework for it, possibly to mock up things like FacesContext. Sadly it doesn’t appear as though there is much thought given to how to test JSF even though testing GUIs has been a pain point for a while now as seen in this post by Rob Williams:

The one thing that I bet is not even on the radar of the JSF team, but I would peg as its biggest shortcoming is its ill-disposition toward testing.

In the comments Rick Hightower mentions having mocked a FacesContext object to get around some things, though there’s no code to be seen. This was the best I could find after a lot of searching on how to unit test JSF. Something seems to be giving off a bad smell and I don’t think it’s my daughter’s dirty diaper.

Caught the new announcement on TSS about IBM’s newest line of WebSphere products. The comments at least at this point are pretty scary. They’re about 75% negative, mostly that RAD is a junk IDE, Websphere has a horrible deploy that takes forever, and all their products dump out useless error messages. The few positive posts are mostly from IBM employees. (2 of the 3 actual positive comments are from IBM staffers as of 9/17.)

I’ve been avoiding dealing with our WebSphere tools since we made a purchase a few months back. My plan was if we needed to we’d open up RAD for doing some portal integration or BPEL work, but pretty much stick with IDEA otherwise. I probably naively assumed that we could deploy to WebSphere as easily as we hot deploy to JBoss 4. Maybe this is all FUD, but I fear not.

Listening to an Agile Tool Kit podcast interview with Bob Martin from the Agile 2005 conference yesterday he mentioned that you really only needed three factors for an agile project:

• Short cycles
• Unit Testing/Acceptance Testing
• Collocation

Short cycles are easy most places. You can generally do them even if the process is very BDUF oriented because you can simply start coding earlier and demo at the end of say 30 days. I’ve found this one fairly easy to institute.

Unit testing would seem easy, but I’ve found this actually a lot more difficult to implement in practice. Most web developers just don’t see what writing tests is going to do for them. TDD is a foreign concept. Then many of the web apps that get written don’t have that large a scope so they don’t tend to have a lot of defects if the developer is pretty diligent doing manual unit testing or the GuruTestsCode pattern. And then most web apps make use of two traditionally hard to unit test items, databases and GUIs.

Collocation seems easy, but mature companies are incredibly anal about turf. They don’t want to give up a conference room for months. Oh, the project might be critical to the company, but we couldn’t possibly give up space for it, where would anyone hold a weekly staff meeting complete with doughnuts.