“Well Paul’s leaving. I guess he finally got fed up.”

The group of developers and sysadmins were disappointed at the news. They wondered why he decided to leave as it turned out he was a key champion from the QA group in pushing a closer working with development. He had a development background and had been key in moving the group from manual testing to working closely with developers on tests and adding automated regression suites.

Early the group had explained they had adopted Scrum in the development group about 18 months prior and it had been going fairly well with now 5-6 Scrum teams. One of the biggest successes had been the closer work with testing. And a familiar problem area had been the problem in getting the true product managers to attend the Scrums as they largely delegated to business analysts and much was lost in the translation.

Apparently the QA team was going to take this hard as Paul had been a champion of theirs in evolving their practices and fighting for respect for QA at the table. It sounded like he had pushed hard and been denied many things because of an unwillingness to imagine QA outside of their traditional role. This shop also had the Mercury suite of testing tools which often is a sign of a dedication to focusing on bug databases and record and playback style automation that doesn’t go nearly far enough in improving the effectiveness of QA.

I hope they succeed as the people I worked with all seemed bright and dedicated to improving things, but a couple of these items are classic warning signs in an Agile adoption that is likely to run out of steam.

• Agile champions like this QA developer pitching in the towel.
• Product managers delegating day to day involvement in the Scrums.
• Use of less than Agile style tools like the Mercury suite.
• QA still having a real perception problem in the organization.

I certainly hope that this test lead doesn’t turn out to be a canary in the coal mine in regards to their Agile rollout.

• Gartner and many tech magazines pushed hard that this was the wave of the future. We haven’t had a tech hype cycle since.
• At a high level the story was compelling, especially the idea of working closely with the business.
• Enterprise vendors needed a new story to sell complex, high cost software after ERP packages started having so many expensive failures, and app servers were largely commoditized by the success of JBoss.
• As a baseline XML had become well understood, and web services were a much easier integration story than CORBA.

So a large number of IT shops jumped in to build their SOA solutions. Some efforts crashed and burned completely and the organization walked away. Others fought through the learning curve, the mass of WS* specs, and delivered some useful services. Still others worked with large system integrators and delivered solutions that were little more than overly complex integration services with large XML payloads presented as a grand new SOA Architecture.

Many others sat out the the whole SOA revolution. They didn’t go out and buy an expensive ESB/BPEL/Composite Application Suite. They let others go through the pain and tried to decide if it was worth it. In the Java space it was similar to the large number of shops who decided to pass on EJB and just stuck with web containers like Tomcat.

What I see now out in the field is a number of those IT shops taking a second look at SOA. There are a number of factors that make it worth taking a second look at SOA:

• Integrating with other organizations these days often assumes you can hook up to a web service they already have.
• The testing story has gotten better, even if much of it is still functional testing.
• The tool vendors have created reasonably decent tools unlike the early generation that were plagued with bugs
• The open source solutions things like Camel and ActiveMQ are proven
• The cloud computing meme is putting an emphasis on thinking and utilizing services to create a complete application.

As I’m out at client sites over the next year I expect to continue to see this trend increase with many sites taking a second look at implementing some sort of SOA. (And yes SOA is still a fuzzy term that I don’t hope to define here.)

• JUnit 4 Hamcrest Assertions with Complete Examples

Everyone has that trunk of old junk tucked away in the attic. It’s almost spring and time to think about getting organized, tossing out old junk, and having a garage sale. Apache has managed to create an online concept of a software attic. Old open source projects that have outlived there useful lives can be retired there. The concept is intuitive and useful in a world with hundreds of thousands of open source projects, many abandoned early in there life.

I’m not sure how long the Apache attic has been around, but I came across it accidentally. I’ve been doing a lot of architecture assignments recently which often involves digging through big source code trees to get a sense of how their development has evolved. In Java land I run into dozens of different web frameworks, and I came across a project utilizing Apache Beehive. I recalled it was some extra XDoclet like commented annotations on top of Struts that was adopted by Weblogic as their default framework years ago. I’m all too familiar with classic Struts, but now I needed to go look up Apache Beehive to see where the framework was currently.

It didn’t take too long to arrive at the Apache Attic page. The mission was stated as such:

The Apache Attic was created in November 2008 to provide process and solutions to make it clear when an Apache project has reached its end of life.

Brilliant! Explaining that the time has come to evolve the codebase is much easier when Apache has officially retired the project. Unlike so many other open source projects I don’t have to do the following investigation on arriving at some SourceForge page where it appears the project has been abandoned. I don’t have to make an argument that though despite a few check ins in the last year that on active projects there will typically be hundreds of check ins and that the project is essentially dead. I don’t have to point out that despite having a plugin architecture for some framework there are only say 5 plugins that have been developed and the last one was 3 years ago. And finally my explanation to management has the official endorsement of Apache.

I’d like to encourage more of this in the future. I await the day when Struts Classic moves to the Apache attic.

The image above probably needs a bit of explanation. After having a lingering todo I finally made a donation and requested a Green Clean Code band from Uncle Bob Martin. I was at a talk of his at SD West 2005. At that point he pointed out a rubber band he was wearing that he would snap on his wrist every once in a while to remind him to run the tests. It was a mark that he took TDD as part of his professional duties.

The green band you get sits at the top of the image. The yellow band below wasn’t a warning type band. The words on have worn out, but it said ‘Go Kenji!!’. Kenji is the son of a neighborhood friend who was diagnosed about a year and a half ago with Stage IV Neuroblastoma. It was heartbreaking to see him go through chemo radiation and finally a stem cell transplant, but he’s a happy cancer survivor today. Today was a good day to retire the band. Cancer is a nasty disease, but it’s better to move on as soon as you’ve vanquished it.

So next time I run into anyone I’ll be wearing this band as a reminder to always keep my code clean with tests and refactoring, even when that code is hairy or written in some language and frameworks that are inherently hard to test.

The fact of the matter is that UI based testing should be used for UIs: that’s it. You should not be testing your full application end-to-end through a UI Testing tool. First of all, that sort of testing couples some of the most important tests in your system to one of the most volatile parts of it.

–Michael Feathers

I understand the frustration he speaks from, but I’ve always realized that you don’t really want to completely try to test through the front-end of the application. It can be useful with legacy systems to get a minimal test harness in place. With the right testers I’ve even seen some of the Mercury products used effectively for UI testing, though it probably required a 3-1 ratio of QA to developers and the tests were not customer tests, but written more as a regression suite.

My use of functional testing tools like Selenium has generally been for a spattering of end to end tests and some amount of customer tests. I’ve never really tried to achieve a high level of coverage with these tests. Obviously testing the business logic through something like Fitnesse is more effective or even setting up BDD style tests tend to make better customer tests.

I’ve actually been saddened over the past five years or so to see that tools like Fitnesse haven’t seen more adoption. I think the BDD development has put more of a focus on developing customer style tests, but in general if there are automated end-to-end test suites in place there often overly reliant on something like Selenium.

• 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.

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.

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.

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.