Developer Expectations

I came across a note of mine from last year on my baseline expectations for developers:

  • All code is checked into source control on an hourly basis or at most daily.
  • Every project has an automated build. (Maven, Ant)
  • All projects are setup in continuous integration (Hudson)
  • All code follows the current Java/Groovy coding standards.
  • Unit test coverage of new code must meet a 70% target. TDD is preferred.
  • Code reviews or regular pair programming are required.
  • Code should meet a standard of low cyclomatic complexity through refactoring and design.
  • Some level of functional, integration, and acceptance tests should be performed.
  • High value documentation is maintained.

Multiple IDEs

According to a Forester report the multiple IDEs for Java developers is standard practice:

While Eclipse is common, it won’t become the only Java IDE in enterprise IT shops any time soon. Less than one out of five Java developers have a single primary Java IDE and no other.

— Jeffery S. Hammond (Forrester Research)

IDE Usage Trends

As a victim of attempts to standardize on a single IDE, this is a good counter-weight argument. My personal experience is I primarily work on Java code in IntelliJ IDEA, but every once in a while I want to use some specific Eclipse plug-in. More regularly I’ll drop back to TextMate for some Groovy or Ruby work as well.

Despite the efforts of commercial vendors to sell IT management on the concept of higher productivity with their brand of IDE, the idea hasn’t worked. At the end of the day as a developer in any shop I want to know I can pull down a codebase and run an automated build with no IDE at all. I don’t care if the original developer did it in Eclipse or Netbeans. The key to being a successful coding shop is to remember that IDEs are just tools and should never be required to build, test, or deploy an application.

Java Development Skill Defaults: Spring/Hibernate/jQuery


Not too long ago a local recruiter noted at a JUG meeting:

“I don’t care what else you have on your resume, but you have to have Spring and Hibernate. I know it was all EJB and SOA just a few years ago, but now if you don’t have Spring/Hibernate you’re not getting past the HR screen.”

As a development manager and even in my professional services role I tend to screen dozens of resumes. I have noticed the preponderance of Spring/Hibernate taking over the usual emphasis on EJB and Struts on the average mid-level java developer. It’s actually a pleasant change to know that the open source community ended up victorious in the marketing war over the official specifications.

Knowing Spring can mean all sorts of things since it’s a fairly large framework. At a minimum I expect a developer to have an idea of using it for dependency injection, but it’s nice to see some exposure to Spring’s AOP concepts, Spring Security, or even something like Spring Batch. It’s a bounus when they have exposure to something like Grails which has been added to the Spring family and wraps much of the low level Spring items in a nice DSL framework.

With Hibernate most developers have left behind either the old hand rolled JDBC DAO patterns or potentially entity beans. Generally, I expect they can handle any sort of mapping and understand things like named queries, lazy loading, and second level caches that can catch developers new to Hibernate by surprise.

I’ve also noted that jQuery in the last year or so has largely become the winner among Javascript libraries and is typically the most common experience I see on resumes. The days of getting by with largely full page reloads for any new request are gone and the Web 2.0 sites have increased UI expectations even for corporate users.

Looking back a few years it was still the rare corporate shop that cared about frameworks like Spring or Hibernate. The emphasis was on heavyweight solutions like classic EJB or closer to the metal approaches like rolling your own JDBC for every database request. The progress to Spring/Hibernate has been an impressive win for developers wanting something simpler.

I do have a few regrets that JUnit and unit testing are still not a default requirement with most development shops. Almost every java developer has the keyword somewhere on their resume, but I screen enough people to know usually that means they’ve written a handful of unit tests for perhaps one project in their career and really don’t understand the value of it.

I also regret that in Java land there are not a handful of default web frameworks. Instead we have dozens of options. .NET, Python, PHP, and Ruby have been more successful in this arena with a handful of web frameworks to choose from in each camp. Usually if you move to a new job you’re going to have to get up to speed on yet another web framework, because the options are so splintered. Maybe this will consolidate in the next few years. At least with the new languages on the JVM you’re seeing only one or two web frameworks like Groovy with Grails, Scala with Lift, or even JRuby with Rails. The example in Ruby with Rails merging with Merb for 3.0 is something the Java world needs to do more of.

So if you’re a java developer and you haven’t had any real exposure to Spring and Hibernate, I’d advise at least spending some time with some tutorials at home. The economy is bad enough that you never know when you’ll be dropped back onto a fairly hostile job market and you’ll at least need them as baseline skills.

An Open Letter to Helpdesk Managers on Developer Admin Access


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.

JUnit Not a Default In JDeveloper 11g

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.