Productivity Tip: Fail Quickly, Succeed Quickly

Ugh, I'm in a bad spot. We're shoring up a release and I'm helping our testers with their regression tests. We're now running all the old test cases from the earlier iterations. Expectedly, some of the older test cases are failing. My job is to provide some explanations as to why the test cases are failing. It's been going well, until today.

I hit a really bad set of tests. The thing about these tests is they take a long time to run and a long time to fail. Oh, they're brimming with NullPointerExceptions that are caused by some bad assumptions that were made about 6 months ago. Fixing the NPEs is no big deal, but finding them is taking progressively longer. When I started this morning I could get to the next NPE in a few minutes. Now we're taking a good 20 minutes. I think the whole test case should take about 25 minutes to run, so we can't be too far away.

The good news, we have excellent coverage of all our test cases. The bad news, when I start a test case I have a 15+ minute void of time where I'm waiting for the next thing to do. I'm filling the void by helping my teammates with their issues, but the voids remind me of a dangerous programming rut I've found--time voids.

Time voids are the things that regularly block a programmer from doing their work. The most dangerous ones to me are development environments that take a long time to set up and require frequent setups.

When I do development I try to iterate through a cycle of setting up a test case for what I want to do, validate that the test case doesn't currently work, writing just enough code to get the case to work, and then validating that it works.

Time voids come in when a workstation takes a long time to perform one of those steps, usually it happens when an environment is being rebuilt or a server is starting up.

Ideally, I'd love to have those necessary delays take a few seconds. Unfortunately, there are times when those delays are minutes if not tens of minutes. That's a productivity killer. The biggest problem with a regular delay is everything you do becomes very expensive. Trying out an idea doesn't take a couple of minutes, instead it might be half an hour. It might cost a day.

What do you do in the time when you're waiting for your system to catch up? You can wipe out your administrative work, clean up your documentation, read documentation, work with others. Probably the best thing you could do is figure out how to eliminate the time voids and get to an environment where failure comes quickly.

Ah, nothing prepares the pallet for the taste of success like the sweet smell of swift failure.