Coding Frontier

Code Coverage Goals

I haven't talked about it yet on this blog, but I am a big fan of unit testing. If you care about the quality of your system, all code should always be tested. I hear this excuse and that from my fellow developers about why certain code wasn't covered. Maybe they don't have time. Maybe they don't believe it is worth the hassle. Maybe it was "too hard". The bottom line is that, for whatever reason, unit testing just wasn't a priority.

Enter management. In their infinite wisdom, they decide to inspire developers to start writing unit tests by creating a performance metric based on code coverage. This will surely fix the problem, right? Now that the test coverage is tied to the year-end bonuses, the developers will definitely make writing them a priority!

Why Code Coverage Goals are Bad for Your System

You need to be very careful when you make performance metrics for code quality. If you make a goal around executing lines of code in unit tests, then that is exactly what you will get. Instead of writing tests based on the requirements or what the code is supposed to do, they will be based on the gaps in the coverage reports.

Developers will start executing code left and right but that doesn't mean that there were actually any tests or that any of this code is verified in any way. What it means is that it was executed. There is no guarantee that any asserts were included or meaningful. There is no guarantee that exceptions aren't caught and ignored. There is no guarantee whatsoever that any of that code was, in fact, tested in any way.

This is considerably worse than not having test coverage in the first place. At least when the code isn't covered, you know exactly what was tested and what wasn't. When everything is being executed, you no longer have any clue what is actually being verified. You are right back to square one when you had no testing whatsoever.

Why Code Coverage Goals are Bad for Your Staff

For starters, motivating people with money is easy, but not effective. If your employees work at your company for the money, then their loyalty is to the money and you will have a very tenuous relationship with them. Not only that, but when someone else offers them more money, they will jump ship in a heartbeat. Oh, and you don't have the best pay in town. You may think your package is "highly competitive", but there is always someone who will pay more than you do and you can rest assured that once your employees figure out who that is you will lose them.

I read a great post about this on the Venture Hacks blog called We don’t pay you to work here. It profiles a book called Hidden Value that goes into great depth about this. I would highly recommend you at least read their post on it. Ultimately it boils down to the fact that money only motivates people to quest for more money.

So What Should We Do?

The root of the problem is not that the system is not covered by unit tests, but that your developers don't believe in unit testing and hold it as priority #1. Installing monetary goals around coverage numbers will do little for your application and only serve to annoy your developers. If you need a measurable goal, a better one might be how many defects are found by your QA department and remind people that if the code is properly unit tested, the defect numbers will be considerably lower, if not zero. 

The only solution to the problem, however, is to get your developers to believe that it is essential. Changing people's beliefs is a hard thing to do. The first step is to make it clear that it is important to the company and not just by saying it, but by acting on it.

My recommendation: check the project plan. It needs to be considered the flagship part of the development life cycle. If unit testing isn't a major part at the start of development, then you are sending a clear message that it isn't really that important to the company after all.

Easy Rewards for Good Behavior

I worked on a project a few months ago that sucked the life out of everyone involved. I'm sure you know the kind. It was one of those with a severely condensed timeline because it was horrendously underestimated prior to any work beginning. There were lots of moving parts and separate teams working on things simultaneously, all of which needed to go in correctly otherwise everything was in vain. My team busted our asses for months and got the project knocked out, on time, and without any production issues. The other team dropped the ball and my team had to pick up the slack. In the end though, we all got it done and we got it done right.

That was wonderful! We were all very excited and all glad that we actually accomplished this seemingly insurmountable feat. Once all was said and done, however, we didn't hear a peep from management. Not even a, "Great job!" Nothing. But that's fine. I like to be busy and had a great time on the project, although you may not have known it if you spoke to me at the time. When I am under an abnormally gigantic amount of stress, like most people, I am not always chipper.

Anyway, our PMP thought we did such a fantastic job that she ran it up the flagpole and tried to get the team a reward for going above and beyond. It almost made it through, but was crushed by the CFO. Again though, that's fine. I really don't expect to get any extra rewards for doing my job. I mean, I am just doing job after all. For some reason though, this project came back to haunt me tonight. I was thinking about everything we went through and how passionate the PMP was about getting us a reward for the work we did. I got to thinking that there is a really simple and meaningful way to reward professionals for doing great work and it doesn't cost a thing.

All you have to do is go onto LinkedIn and write a recommendation. It only takes a few minutes and is actually a meaningful thing to have. It is something personal that another professional wrote about you and that you can carry with you for your entire career. It is something that shouldn't be copy-and-pasted from the letter provided with the Corporate Bullshit Award, or whatever nonsense your company gives out to people, but something specific about that person and what they accomplished. Maybe some people wouldn't care, but I think that knowing that someone took a few minutes out of their day and wrote an unsolicited open and public letter about you would mean a lot.

I don't blame that PMP or anyone else for not writing a recommendation in that instance. I mean, I just now thought of it and this all happened months ago. What I do take away from this is that the next time I see someone else going above and beyond the call of duty in a meaningful way, I need to write one for them without having been asked. It is nice to share a little love once and a while. Pass some along and maybe you'll get some back.

jQuery Extensions Aren't Just for Plugins

I don't typically think about extending jQuery for page specific code. Normally I reserve that for plugin authoring, but I was working on a screen the other night and I found myself calling a function in a few places and passing it a jQuery object.  This function would iterate over the elements and do blabady-blah whatever.  I realized that I could make this a whole lot cleaner by writing it instead as a method on the jQuery object. Originally it looked something like this: [js]var MyPage = {   actOnItems: function(items) {     $(items).each(function() {       ...     });   },   needsToActOnItems: function() {     MyPage.actOnItems($("div :input"));   } };[/js] That isn't a bad way to do it necessarily, but I think it makes the code a lot simpler and cleaner to read if I just extend jQuery with the method instead. [js](function($) {   $.fn.actOnItems: function() {     return this.each(function() {       ...     });   }; })(jQuery); var MyPage = {   needsToActOnItems: function() {     $("div :input").actOnItems();   } };[/js] The jQuery extension stays with the rest of the page specific JavaScript, but now we have abstracted it out so it can be used like any other jQuery method. This also allows us to chain it and reduce the risk of confusing the future maintainer of the code. Be careful not to go crazy with this though. As with anything, only do it when and where it makes sense.