Speed up development by slowing down

When Justin James realized his work was getting buggy, he took a step back and figured out why. Learn how his experience could help you from making the same mistake.

Every developer has at least a few bad habits. The longer I write code, the more open-minded and honest I am about my flaws. Most of these bad habits I uncover myself and hopefully go down the path of correcting. I believe this process is vital to getting better at anything you do, and software development is complex enough that there is always tons of room for improvement.

I had noticed (and so did others) that my work had started to get buggy. Sure, we all let a bug slip through our initial testing from time to time before it gets to QA, but I was letting some really obvious, easy-to-fix bugs through. It was not acceptable, and certainly not at the standard I hold myself to. It was time to reflect on exactly what was going on, why I was making these mistakes, and how to fix them.

I took an honest, comprehensive look at what was different, and I quickly narrowed in on the problem: I had started trying to do too many things at once. Long-time readers know that I periodically criticize the notion of multitasking because in truth, most people are not nearly as good at it as they think. I've always been convinced that trying to do two things at once makes each task take 50% longer with 50% worse results. And you know what? I proved it to myself.

When I saw what my mistake was, I put the brakes on it. Not only did the bug count go down, but the actual speed of development went up. The bulk of the time spent in the development cycle isn't the actual writing of the code -- that's just a bunch of typing and some mousing around -- it's in the back-and-forth: compiling, deploying to servers, testing, communicating with others, and so on. The more accurately the work can be done, the more you cut into the other things. In my current projects, it takes about 2 - 3 minutes to get code from my machine to a development environment ready for testing. Spending extra time but eliminating dozens of these cycles getting things right is a net gain. Even if it means that the time I spend goes up a little bit, it cuts out so much back-and-forth with the testers that it is a net gain.

As I have said in the past, trying to save time and cut corners by multitasking does not make sense, and when doing something like software development that requires a good amount of concentration, it makes things even worse. One of the best ways to speed up your development cycle is to stop trying to do so much at once, focus on one task at a time, and do it right the first time.