Two of our senior developers vented on JSF to me today. We’ve been using JSF on two projects now for about a month and a half and the experiment hasn’t been going so well despite the marketing hype. One developer explained that he wanted to implement a simple templating solution using Tiles. Turns out you can’t forward directly to the tiles, like in Struts. So there’s probably another option or some way to workaround this, but it can’t leverage well known solutions easily.

Then another developer on our other project explained that the JSF parts were driving them nuts with debugging hell. They tried to implement an AJAX style auto complete in a text field. Unfortunately the JSF pages keep having a problem somewhere, but there’s no real debugging output. Just press the submit button and nothing happens. JSF swallows the exceptions in a lot of cases and doesn’t output any sort of useful error message.

Of course these are anecdotal evidence, and they probably have at least some sort of workaround, but it does point out that JSF has not been an easy or productive adoption so far at least for our shop. Of course tomorrow I’ll be doing some pairing on one of these projects so I’ll get to understand the issues a little more first hand.

“Oh, if we’re going to hook the project up to cruisecontrol I better write some tests.” –An Unnamed Developer

I’m not sure the fact that I spent a day doing a class on TDD last week has completely sunk in. Tomorrow I hook up cruisecontrol and maybe do some pairing so we can make some progress on this front. Maybe it’s time to invoke harsh measures and start failing the projects for not enough test coverage. I might feel like an ogre, but at least I’ll be a test first ogre.

I have a developer who got interested in trying out JTest from Parasoft. He talked to a sales rep at a conference and got a 30 day copy or something to try out. It’s a fairly pricey product on its own around 5K per seat if I remember correctly. I’ll be getting a sales quote soon so we’ll see if my memory is right on that one.

It appears to capable of generating a pretty good set of unit tests, but the biggest concern is that it sort of inverts the idea behind test driven development where of course you have to write the tests first. For legacy code this is probably a pretty great tool. You checkout the codebase, run JTest against it and suddenly have a fairly decent set of tests that you can build on. Jeffrey Fredrick, a developer at Agitar a competing product to JTest, claims that it can be used after you’ve done TDD to increase your code coverage.

Since we’re in many ways still in the initial stages of implementing TDD with my developers I worry that adding a tool that works after you write the code will reinforce the wrong ideas. It also adds yet another tool to our current slate of new technologies that everyone has to come up to speed on. If all of the developers had fully integrated TDD into their daily process then adding a tool to increase coverage might be a lot more reasonable.

On the other hand, we’re still dipping our toes in the water with TDD and I’d be happy to see any significant improvement in unit test coverage even if a good portion of it was from an automated tool. And some developers are more likely to adopt something if they have a cool new tool to go along with it.

Not sure how we’ll proceed with this at this point. We may buy a license or two and try it out on one project, or we may just pass for now because even that cost is a little too high. I’m not sure why companies don’t realize that $1000 and up is generally the point where you decide not to adopt the tool just on cost. We actually have a tool that costs about $20,000 per seat and we’re in the process of migrating the last dependent code on the tool out so we can drop it completely.

I was talking to one of my senior developers this week about curly braces. We’ve instituted our coding standard around The Elements of Java Style and we’re trying to hold to a strict interpretation. I even held a series of lunch and learns to help with adoption. This developer who has quite a few years of experience argued that:

“The curly braces on a new line really help me line up the nested blocks in conditionals. Without that I often miss a curly brace somewhere. Is this really something we need to do?”

At the end of the day I have trouble really believing wholeheartedly in no exception type standards, because so often I’ve seen them used to enforce bad ideas. By default all the Java coding standards assume you’ll have the curly braces starting on the same line because that is Sun’s standard. Defacto most java code out there follows this standard. At the end of the day this seems like a silly battle to fight the more I think about it.

Developers can get pretty religious about there preferences on this, but I’m planning on moving the placement of curly braces to the optional list, or at least let the developers pick a style on a per project basis. I know we’ll take a small hit in legibility since we’ll have two different styles, but the tradeoff is pretty minor.

I’ve seen a suggestion on a blog somewhere that a lot of this thrashing over coding conventions would disappear if the compiler enforced them. At that point there’s no argument anymore. I find that argument pretty convincing, but for now we still have a lot of options with conventions.

Never hurts to have your developers come back to you with strong arguments that some process isn’t helping them get the job done. Often they’re right.

I’ve noticed that on some of our Scrum projects we sometimes have a gap of a few days between starting the next Sprint. Often this is because getting time arranged to meet with the customer can’t be done on the day after the Sprint ends necessarily.

I think we’d be better off if we could start the next Sprint right away, but given the fact that the business side of our organization and our PMs haven’t really embraced the idea beyond the official pilot it appears to be something we’ll have to accept. At the end of the day we’re delivering on the Sprints and that’s the critical part.