Randy Johnson (The Big Unit)

A common evil that often rides along with unit testing is the unit testing metric. These metrics come in many flavors, including percent code coverage, number of tests and percentage of tests passing. Like any statistic, there is the potential for misuse and misinterpretation, which is the point of a post on Javalobby titled “Effective Code Coverage (and Metrics in General)“.

Management mandates to have X% of code coverage.
… Upper management, without a clue about the health of the codebase, mandates that developers should reach X% of code coverage. Period. … In many cases, when the codebase was not designed with testability in mind, I’ve seen developers writing a lot of test cases, without any assertions! All the tests pass, and the code coverage goal is met.

This seems like a pretty easy problem to solve. Review the unit tests. Ensure that there are actual assertions (i.e. tests) going on inside each test method. Problem solved.

Unit tests are code. Just as code should be reviewed, both by peers and architects, so should unit tests.

I have never seen this happen.  However, if I ever do encounter it, here’s what I would do (in this specific order):

1. Re-examine the company’s culture of mandating unit testing, and determine what it was that would cause otherwise reputable developers (you don’t hire anything but, right?) to go to such lengths to play the system.
2. If you can’t find anything wrong with the company’s culture, look harder. A good, honest developer will not do this unless pushed to the limit. Are there abstract and unrealistic deadlines being set? Do they have the tools they need to write the tests? How about training?  The company, from the top executive down, must embrace and support developer-driven testing.

What I have seen, however, are projects with a lack of unit tests. This is almost always due to technical leadership failing (architects and team leads) to emphasize the importance of user testing, or the aforementioned lack of executive sponsorship.

You’ll be less likely to slack off if someone else is counting on you to perform.

What’s interesting is that this wasn’t an article about pair programing; it didn’t even have anything to do with software development.  But as I read this, I had the mental image of somebody standing over my shoulder, watching every little thing I did. I don’t work well in that situation. Yes, performance anxiety. Things that would have taken me five minutes to complete would then become ten.

I think the visceral reaction comes from the lack of trust that pair programming communicates. “You’ll be less likely to slack off if someone else is counting on you to perform” means “you cannot be trusted to work on your own, so we’re going to set someone right beside you and have them watch your every move.” In my mind, knowing that someone is depending upon me to get something to them by the end of the day is all I need to get things done; I don’t need someone to watch over me as I do it. If knowing someone depends upon your work doesn’t keep you from slacking off, why would someone staring over your shoulder?

What are the other reasons?

1. You’ll have to have a 100% increase in productivity just to break even. Because there will now be two people doing the work of one, that “work unit” will need to become 100% more productive. While I do see some productivity increases in pairing (for example, catching the mistake of using a = instead of a ==, or other similar ‘typo’ bugs), but I cannot imagine how paring would double productivity. And if the pair does manage to double their productivity, that’s just breaking even. No benefit.
2. You lose your individuality. You’re now basically working with a punch clock, given that you have to coordinate your time with your pair. Let’s say you’re used to varying your commute time based upon traffic conditions. No more, now that you have to arrive (and leave) with your pair. Need to duck out to see your kid’s school play, go to the doctor, just get out of the office for a while and grab a coffee. Nope, no way, nada. You’ve become a sycophant in the corporate rat race. Yes, the people you use to laugh at. Now you’re one of them, thanks to pairing.
3. With the loss of individuality comes the loss of creativity. Having a pair will impact your trial-and-error process (because nobody likes to have people watch their failures, and trial-and-error is more error than anything else), as well as the time you just need to sit there and think something out. Yes, sometimes a pair will be useful when thinking something (particularly with the hard stuff), but most of the time it isn’t.
4. Interrupaloosa! You’ve managed to figure something out, you’re typing away wildly, your hands barely keeping up with your thought process when: “Um, hey, wait. What does that do?” says your pair. The sound you hear are the boxcars of your thought process being crushed as the train flies off the tracks. Interruptions from the general business day are bad enough, but when you’re joined at the hip by an endless stream of interruptions, you’re productivity is going to plummet. Just like your train of thought goes rolling end over end down the steep canyon.

So there you go. There are my reasons for not liking pair programming. I’m standing by, awaiting the Agile police to come and take me away for having the audacity to doubt The One True Methodology.

Urgh.

There was a refactoring push recently to smooth out the build process for a web application I work with. The .war file being generated was getting bloated, and it was due to many unneeded .jar files being included during the build. The refactoring process involved using some dependency-checking functions with maven. It was a labor-intensive and iterative process. After a few days, it was thought that the effort had completed. After all, maven was no longer complaining about either unreferenced .jars, or required .jars not being found. Not only were there no compile errors, there weren’t any warnings, either. Things looked very good.

That is, until we deployed and tried to start the server. The application server barfed almost immediately after starting the application. The problem: overzealous removal of .jar files from the project’s .pom file. The root problem was that we were looking at compile-time dependencies to determine if .jar files could be removed, we weren’t taking runtime dependencies into account. The fix was to include the dependent .jar files with a “runtime” scope in our .pom files.

The moral of this story is that while unit tests are great, and an amazing tool to reduce project defect count (particularly when used in conjunction with Test Driven Development), it’s not the end-all test tool. In this case, the .pom files, as well as any other changes from the refactor, should not have been committed to source control until after the application was actually deployed (locally, on the developer’s workstation), and put through it’s paces.