It’s almost 2010 and JUnit runners are still an optional download for Oracle JDeveloper 11g. JDeveloper is a reasonable IDE and it’s improved over the years. It has most of the basic features an Eclipse or IntelliJ IDEA user would expect including plenty of refactoring support.

Leaving out JUnit integration was unfortunate. My assumption is JDeveloper is used primarily in shops that are heavily Oracle based and usually with developers who are coming out of a PL/SQL background. Many of them may have done years of Oracle Forms and Reports. PL/SQL has utPLSQL, but it’s never caught on as default tool as you’d see in Java or Ruby.

The introduction to current practices like unit testing, refactoring, continuous integration, and static analysis are critical for shops that are just now moving into regular java development. As far as I can remember the JUnit support has been a standard part of Eclipse for 8 years or more and similarly for IntelliJ. Sometimes you run into organizations that are very comfortable with their software vendors warts and all. When you leave out basic unit testing integration as an optional plugin that you have to go out of your way to install you’re sending a clear message. Unit testing isn’t that important, you could probably just skip right past it. Even Visual Studio 2008 fully integrated unit testing and MS has been late to the party as it is.

A quick word of advice, for users of JDeveloper, the unit testing plugin isn’t really optional. Just consider the extra steps to download it part of the install process.

A common pattern when going through labs for various java classes is the pattern of building some main() method, performing a number of operations and spitting out a bunch of System.out.println()s. It’s an easy way to get feedback and avoid having to start with much context. Unfortunately it’s really a procedural style and requires eyeballing the output to see if things worked as expected.

This isn’t a novel concept, I’m aware that Jeff Langr and Mike Clark have talked about using this technique to pick up new languages. The concept is to remap these sort of lab exercises as TDD style means writing some tests using JUnit or TestNG instead. It takes a few minutes potentially to explain to students how JUnit works, but the concept isn’t much more than understanding executing a main method. There are some good bonuses:

• If they haven’t done TDD, the students get a chance to experiment with it in a classroom environment when they’re already prepared to learn new things.
• They don’t have to do strict TDD to get a benefit, but they can still take a learning test approach. Not sure what a given method will return just write a quick assertion and check.
• You have executable examples to look at long after you leave the class. This can be a benefit when you need to troubleshoot some issue you’re having.
• You don’t have to eyeball the results.

Next time you’re in a lab showing main() methods and getting feedback from System.out.println() just start with a test instead.

Hudson has a Continuous Integration Plugin game that gives you points for successful builds, adding tests, removing TODOs, etc. As a plugin it started out simple, but now allows you to get points based on:

• Doing a successful build.
• Adding new successful tests.
• Fixing PMD, FindBugs, or Checkstyle warnings.
• Fixing a compiler warning.
• Fixing a TODO.

Around a year ago I tried it out with my development team. It looked like a fun way to reinforce good practices, but I wasn’t sure how it would play out. As a dedicated gamer I loved the idea, but development teams contain all sorts of other personalities.

At the end of the year it was a mixed success. One developer really took to the plugin and even reported bugs and modified the rules to make it reflect reality a bit better. He brought up the scoreboard in a few team meetings and gently tried to foster some competition. At the end of the year he easily led the leader board. I had one of the higher scores myself as a caretaker of Hudson since I often ran builds to clarify something that had been configured wrong or to setup a new project. For the most part the rest of the team knew it was there, but never mentioned their score or ribbed anyone about how low or high they were on the scoreboard.

The key behavior you want on any development team is that the developers care about the CI build and fix it quickly when it breaks. As the year went along this behavior began to be integrated within the team. It took a bit of prodding in some cases, but eventually all the developers felt bad if the build was broken for long and stopped to fix the build before moving on again. The CI game may have played a small role in this, but I was happy with the results. I’d recommend trying it with any team and see how your results go. It didn’t encourage any negative behavior and the results could be impressive with more gaming centric developers.

Long ago Scott Ambler discussed the idea of a specializing generalist, an element critical for Agile teams. Stumbling across the definition of a generalist who has developed some deep skills in certain areas, but broad skills in a variety of functions felt natural. As a very old web developer I long ago spread out from my development roots. Passion and a love of learning led to a much wider spread of abilities. Just a few were:

• Project management which I happened into building web sites, intranets, and e-commerce projects. Eventually this would lead to picking up a PMP and moving into a Scrum Master role.
• Java and J2EE after starting my career with Perl and CGIs. I started with raw servlets and JSPs. From there I moved into Struts, DAOs, JSTL. Then to help with consulting gigs and get a broader view of the large J2EE stack I picked up a bunch of Sun certifications ending with the Sun Certified Enterprise Architect. I consider the path of preparing for all the certification tests and the project worth far more than the cert itself.
• Build tools were always a passion as I wanted to automate as much as I could. This led to a long time setting up the ant builds for every project and eventually looking into maven and the wonderful rake of the ruby world. Not too long after I discovered cruisecontrol and started setting up CI for every project. The last few years I’ve focused primarily on Hudson which is a fine build server, but I’m always looking for new ideas in CI servers.

As I stepped into management roles staying a generalist was critical. I can’t speak for other professions, but if you don’t stay well steeped in the technologies and practices that your team do much of your feedback will be dismissed as the ‘Pointy Haired Boss’. You need to be able to checkout the current version of a project, do a build, and talk to your tech lead about why they chose to use iBATIS over Hibernate for the ORM. You need to be able to walk through the code in some nasty legacy project and really feel the pain as a developer explains how the one JSP is 4300 lines long.

It’s also insurance against downturns. If you have skills in a variety of areas and can come up to speed quickly on new technologies many options are open. If you’re a manager who’s let the technology side slip away you have to fight for a very limited number of spots out there. Plus being a specializing generalist means you’re always having new learning experiences which is a great payoff all on its own.

Land the Tech Job You Love turned out to be a good read full of actionable advice for job seekers who just happen to be techies. It covers everything from creating three versions of your resume to preparing a portfolio of work products to take with you to the interview. All of this is good advice.

The hidden gem in the book is the great guidelines for technical managers on how to conduct the recruiting process:

“A hiring manager who wants to get a real feel for her candidates’ skills will ask for examples of work. When I was hiring programmers, I told every candidate that I called in for a face-to-face interview to bring in code samples, printed on paper, so that we could discuss them during the interview. Unfortunately I was definitely in the minority. Ilya Talman, on o the top technical recruiters in Chicago, to me that he estimates only 15% of hiring managers ask to see samples of work.”

— Andy Lester

For developers bringing in their code and going over it gives you a much deeper feel for a person’s development skills than any single behavioral question.

Code samples give you a sense of how the developer looks and how important code hygiene is to them. You can ask about decisions as to why they didn’t refactor a longer method or why they named a class a particular way. In many technical interviews you’re never asked to go through code at all.

If you’re not already requiring code samples for prospective developers I’d suggest trying it out at the next opportunity. You’ll be surprised at the insights.