The default assumption with JSF is that you do drag and drop development in some nice vendor tool. That’s pretty much the vision our vendor sold us as well, but I’m beginning to reconsider it. A few recent things have gotten me thinking.

The first two are comments from two JSF thought leaders on how they don’t use WYSIWYG tools to do JSF:

This is one of the most common misconceptions about JSF. While there are plenty of good tools (and I generally tell people to use them), using them isn’t a requirement, and all of them don’t generate code. I’ve been working with JSF for quite some time now, and I usually don’t use WYSIWYG tools or code generation.

– Kito Mann from a TSS Post

Rick Hightower has a similar opinion:

You can use WYSIWYG tools with Struts or for that matter Swing. No Struts or Swing developer I know uses them. This is the same with JSF. The tools exists, but no developer I know uses them (except maybe to do some prototyping). I can’t stand the stuff these tools generate.

– Rick Hightower from a TSS Post

This mirrors recent comments from some of my senior developers on how the JSF tools and are driving them crazy with all the generated code. Top that off with my own personal bias against wizard interfaces and their known usability issues and I think we might explore some hand coding and compare the results.

I had a lingering item on one of my lists to look into why our Windows build box runs out of memory after 3-4 days of running cruisecontrol. Turns out it’s a quick uncomment in cruisecontrol.bat:

REM Uncomment the following line if you have OutOfMemoryError errors
REM set CC_OPTS=-Xms128m -Xmx256m

Not sure why it isn’t the default.

I sat my two tech leads down last week and went over a draft of our new code review process. They were OK with the general approach and idea, but they did have two things to add:

1. You’re going to present this to the team.
2. We probably won’t need to do these after a little while since everyone will be on the same page.

On #1 I did plan on working up a short presentation to the team, but I understood they really wanted to make sure there was management support for it. Code reviews aren’t exactly popular. And #2 I certainly hope that we’ll have a lot fewer mandatory recommendations, but I think we’ll be adopting them as a regular practice. If the team wants to switch to say some light pairing or we run into other issues of course who knows. At the end of the day I think getting the team to adopt TDD is a bigger goal than having regular code reviews. In some ways it’s really just meant to be a supporting practice.

In a podcast on Drunk and Retired, they talked a bit about how their seems to be a bit of hand waving about how agile methodologies really scale:

Well, like you know, in Scrum, just have a Scrum of Scrums, that’ll work out.

–Cote

I actually giggled on my morning walk because it was the same visceral reaction I had reading the first time I came across the concept. I have pretty much the same reaction to how well a lot of Agile techniques will scale. They all depend on communication and collocation so a huge project team seems antithetical. My general rule is to run screaming from really large projects, or to see if they can be done with a smaller elite team.

Luckily this is all pretty much theoretical in my present world since our largest projects have at most 8-10 developers, and most of them are more along the lines of 2-3 developers per project.

In the tradition of code smells here’s some Enterprise Tool Smells:

• Install time is measured in days.
• Installation involves cryptic steps such as after step 17c, delete these files, then restart the installation script.
• The install software doesn’t fit on a single DVD, necessitating baby-sitting it so you can dump the next CD/DVD when it’s ready.
• Tool promises that regular business people can use it and write business rules in a “natural language,” making code monkey’s irrelevant.
• It has an Enterprise version that installs tons of features, servers, plug-ins, that no one ever uses.
• It uses lots of wizards.
• Company recommends hiring consultants to train you in how to use the tool.
• Despite features like “seamless hot deploy”, any change involves rebooting the server.
• Restarting the service or tool is measured in minutes not seconds.
• No one including the sales team can really explain the licensing terms for all the different purchase options.
• Productivity takes a radical nosedive when tool is introduced, and then mysteriously increases sometime later when employees stop using the tool.
• Support involves filing trouble tickets or issues that are never resolved though sometimes promised to be in the next release.
• It’s in the Gartner magic quadrant.