JTest and TDD

I have a developer who got interested in trying out JTest from Parasoft. He talked to a sales rep at a conference and got a 30 day copy or something to try out. It’s a fairly pricey product on its own around 5K per seat if I remember correctly. I’ll be getting a sales quote soon so we’ll see if my memory is right on that one.

It appears to capable of generating a pretty good set of unit tests, but the biggest concern is that it sort of inverts the idea behind test driven development where of course you have to write the tests first. For legacy code this is probably a pretty great tool. You checkout the codebase, run JTest against it and suddenly have a fairly decent set of tests that you can build on. Jeffrey Fredrick, a developer at Agitar a competing product to JTest, claims that it can be used after you’ve done TDD to increase your code coverage.

Since we’re in many ways still in the initial stages of implementing TDD with my developers I worry that adding a tool that works after you write the code will reinforce the wrong ideas. It also adds yet another tool to our current slate of new technologies that everyone has to come up to speed on. If all of the developers had fully integrated TDD into their daily process then adding a tool to increase coverage might be a lot more reasonable.

On the other hand, we’re still dipping our toes in the water with TDD and I’d be happy to see any significant improvement in unit test coverage even if a good portion of it was from an automated tool. And some developers are more likely to adopt something if they have a cool new tool to go along with it.

Not sure how we’ll proceed with this at this point. We may buy a license or two and try it out on one project, or we may just pass for now because even that cost is a little too high. I’m not sure why companies don’t realize that $1000 and up is generally the point where you decide not to adopt the tool just on cost. We actually have a tool that costs about $20,000 per seat and we’re in the process of migrating the last dependent code on the tool out so we can drop it completely.

Curly Braces Style

I was talking to one of my senior developers this week about curly braces. We’ve instituted our coding standard around The Elements of Java Style and we’re trying to hold to a strict interpretation. I even held a series of lunch and learns to help with adoption. This developer who has quite a few years of experience argued that:

“The curly braces on a new line really help me line up the nested blocks in conditionals. Without that I often miss a curly brace somewhere. Is this really something we need to do?”

At the end of the day I have trouble really believing wholeheartedly in no exception type standards, because so often I’ve seen them used to enforce bad ideas. By default all the Java coding standards assume you’ll have the curly braces starting on the same line because that is Sun’s standard. Defacto most java code out there follows this standard. At the end of the day this seems like a silly battle to fight the more I think about it.

Developers can get pretty religious about there preferences on this, but I’m planning on moving the placement of curly braces to the optional list, or at least let the developers pick a style on a per project basis. I know we’ll take a small hit in legibility since we’ll have two different styles, but the tradeoff is pretty minor.

I’ve seen a suggestion on a blog somewhere that a lot of this thrashing over coding conventions would disappear if the compiler enforced them. At that point there’s no argument anymore. I find that argument pretty convincing, but for now we still have a lot of options with conventions.

Never hurts to have your developers come back to you with strong arguments that some process isn’t helping them get the job done. Often they’re right.

Gaps Between Sprints

I’ve noticed that on some of our Scrum projects we sometimes have a gap of a few days between starting the next Sprint. Often this is because getting time arranged to meet with the customer can’t be done on the day after the Sprint ends necessarily.

I think we’d be better off if we could start the next Sprint right away, but given the fact that the business side of our organization and our PMs haven’t really embraced the idea beyond the official pilot it appears to be something we’ll have to accept. At the end of the day we’re delivering on the Sprints and that’s the critical part.

Locking down IM

I heard an especially annoying podcast by Nancy Flynn on using IM at work. The whole tone of the talk was how companies needed to get control of IM clients because their “rogue” employees might expose them to some sort of litigation risk. These employees are dangerous because they download these IM clients and use them to communicate more effectively.

The solution of course was to lock down everything and establish strict policies. What goes unspoken is that by locking down a tool like IM you drain it of effectiveness. The underlying assumption is not to trust your employees which is where a lot of bureaucracy comes from. The reality is bad employees will abuse any privilege, so you’re just taking things away from your best employees.

Of course personally I try to be careful using IM much because it can be a pretty annoying interruption if you pay to much attention to it.

Blowing Up An Overhead Presentation

This Monday as I was typing my way through a demo in front of 7 developers I noticed as I made typos, etc, that most of the comments were coming from the front row. Turns out after I talked to several people in the class that it was hard to read code in 12pt type at 1024×768, especially from the back row.

So far I’ve found two fixes. I can change the default font size to about 16pt in IntelliJ IDEA or since I’m on a Mac I can set the universal accessibility option to zoom to about 1.5 times when I hit the Apple-option-equals combo. I’ll probably just go with the 16pt size option though