I know you wonder why developers come charging into the help desk right after you’ve delivered the sparkling new machine with 8GB of RAM, dual monitors and a quad core processor. They start babbling about how they need admin access or you might as well give them there old Pentium 4 box so they can get something done. Their face is flushed with frustration and they seem very passionate about this. You try to patiently explain that they can just fill out a ticket and they’ll send someone over to update their JDK or install Visio. They just throw up there hands stomp off, and before long you’re talking to a development manager. What is the big deal really?

Developers live and breath on their machines and the good ones are constantly trying new tools, updating old ones pulling down app servers, setting up local databases or LDAP servers. Most of them have a high end laptop at home and a cushy two monitor setup that is often better than the one provided at work. It frustrates them that the company doesn’t understand the gains in productivity they could get just updating the hardware. Then the day comes where they’re granted a new machine and they dream about it waiting weeks for it to show up.

They come in one morning and see the new machine setup and deployed. Their old machine is missing from the cube, and that causes some concern. Ignoring warning signs of danger they log in with their trusty network login and start running through a list of the most important things to get installed first. They login, fire up IE and go grab an install of Firefox. Starting the installer a dialog box shows up informing them that access is denied. Blood pressure doubles in the next minute. Then they try to stay calm as they dial up the help desk to get admin rights granted to the account.

A cheerful voice on the phone informs them that the current policy is that no one gets admin access to their desktop. The help desk will install all software. The developer explains that they had admin access on their old machine. Yes, but the new policy is being rolled out with the new hardware. At this point the developer slams down the phone and sprints over the to the help desk to explain the craziness of denying admin access in person.

As a development manager soon after they’ve ranted at the help desk I get involved and have to calm myself down for a few minutes, because if anything I get more frustrated with these one size fits all admin access policies then my developers. I simply send off an email at first listing the reasons the developers will need admin access:

• Developers install and update their tools on a regular basis and ruby or java development involves a constant updating of libraries.
• Developers need to install open source tools on a constant basis such as IDEs, editors, diff tools, browsers, etc.
• Waiting days or weeks for a help desk staff to install something is completely untenable when doing weekly iterations.
• It is an incredible waste of the help desk’s staff time to come over and update or install software on probably a daily basis for even a small development team. You’ll almost end up with one person per 10 developers to just do installs.
• Developers are savvy enough not to fall for trojan horse software and other items that say an admin might install without realizing.
• The fact that the developer’s machine might be hard to recover if it has a massive hardware failure is a perfectly acceptable risk and developer’s don’t expect the help desk to restore it back with all of there tools intact.

To use an analogy not allowing your developer’s to have admin access to their desktops is like having to have a personal escort to unlock the bathroom for you every time you need to visit the restroom.

So I apologize for the developers who appear half-crazed and unwilling to follow a simple admin access policy, but hopefully I’ve been able to give you some insight as to why they are so passionate about it.

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.