I am constantly amazed of the default assumption that QA people are just a step above helpdesk staff on the IT skills ladder. In my experience QA people range from test monkeys who just bang on the links and report the occasional bugs to scripting gurus who can seemingly invent 20 new ways to break an application in 10 minutes. This spectrum closely follows developers who range from code monkeys who learned just enough VB to be dangerous 10 years ago and can’t code their way out of a paper bag to gurus who can rip out an application under seemingly insane deadlines.

So why do so many IT folks assume that the testers are just an after thought and they couldn’t possibly code something, not even a simple Perl, Python, or Ruby script to push test data through an application. Not only that we couldn’t possibly allow them to install a scripting tool to let them try out some automation. No, they might blow up their machine and then the help desk staff might get a call to help clean up the mess. Never mind that that would be the help desk’s job or that fact that they are a lower level support staff versus QA staff who directly impact the company’s software products.

I think I find the low opinion of QA’s abilities most annoying because it mirrors the same sort of elitist thinking I see on a lot of software teams. You know the situation. Say the team has 10 developers on it, but everything is stratified between 8 front end developers who just code some JSP pages and two ‘real’ developers who build the ‘backend’ code that really makes the application go. Many of these front end developers have been stuck in a ghetto of just doing the GUI because you couldn’t dare expect an average developer to be able to say write a DAO. I find expecting all your developers to be able to code all the layers of an application is amazingly more productive. Sure some developers are never going to be as good as some of your stars, but knowing they can handle any part of an application even if it takes longer is a lot better than explaining to your customers that you can only handle one project at a time. (Better yet one of your uber developers leave and no one knows how to maintain the application.)

Our first official Scrum project finished it’s first Sprint successfully today. I’m a bit jealous since they have institutional support, while I’ve run multiple Scrum style projects without buy-in from the business. In fact our PM group has officially explained to us that we can’t use Agile methodologies.

We’ve adopted the bulk of the practices such as daily standups, 30 day iterations, planning meetings, project retrospectives, and a product backlog. Still we’re stuck in a traditional waterfall process for the overall project, so everything moves slower and we have to wait a lot because we’re the only ones running a 30 day Sprint.

Our culture is still very much waterfall oriented. We’re backing out code on a project right now because our process only allows features that are fully documented to be added even when the customer wants them. We’re so set in our process that just removing access to the new features isn’t good enough. We have to remove all the actual code to comply with our process. If we don’t our QA team won’t test the application at all.

It’ll be a nice change when Agile/Scrum becomes the default practice instead of only being officially allowed on pilot projects.

I got around to a long ignored todo today over lunch at my desk–adding checkstyle to our cruisecontrol builds. It took about 1.5 hours mostly because the default rules in sun_checks.xml are a bit too extreme and have to be commented back into some state of reason. My favorite custom rule was the following example in the checkstyle documentation:

<module name="GenericIllegalRegexp">
      <!-- . matches any character, so we need to
         escape it and use \. to match dots. -->
      <property name="format" value="System\.out\.println"/>
</module>

No more System.out.println() for us. Currently we probably won’t fail any project for having violations, but it will help reinforce our newly adopted code reviews.

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.