Many managers and developers think about improving productivity. As with many things, productivity is in the eye of the beholder.

We used to measure productivity in lines of code. That led very quickly to believing that the developers produce what they type. Well, what do they do the rest of the time?

In fact, if they are producing code, we can do something better: We’ll get the smart developers, and call them architects. They cost a lot of money, but it’s worth it, because they can think, and we don’t need many of those. They can just put their thoughts on paper. Now we’ll take the not-so-smart ones and hand them what the architect has thought of, and they will do the work. And get this, we’ll pay them less, because they just need to type!

I just saved the company millions!

It may sound stupid, but you’ll still find people believing that.

The main bottleneck, as well as the productivity engine of developers is their mind.

To increase our productivity, we’re looking to download what we’re thinking into the computer in a fluent way.

We call that flow. And we’d like to maintain it. When we’re in that zone, we can produce software very quickly. In fact, the wonderful productivity tools we have to automate the repeated operations we do, help us not get stuck once this engine is running.

Working with tests speeds things up because of the continuous feedback we get on our work. The more tests we have, we get better, quicker feedback, which keeps us on track.

If tests are the gas paddle, what are the brakes?

Enter the debugger.

This is the one of the most sophisticated tools there are, allowing developers to find problems. As technology moved forward, debuggers became more feature-heavy and precise, and gave us all we needed to isolate and find problems. It’s almost like toolmakers say: “It’s alright, you can make mistakes now, we’ll help you solve them later”.

They hold our code hostage, and we’re giving in to these terrorists.

Because that “later” is costly. Debugging an application take a very big chunk of a developer’s time. Without tests, it is the only way, to find where a bug occurred. Sure, you can print out logs, and go through them, but where’s the fun in that?

Instead, you need to wait, and repeat, and after you fix the problem, debug it again. And maybe do that again, and again, until you’re sure the problem was fixed.

Without small tests, we need to debug the entire system. With small tests, we need to debug a lot less. In fact, just by looking at the test code we might understand the scenario, and relate it to the code. It’s like short-circuiting the process of "solving the problem".

Working with unit tests minimizes the time spent in the debugger. That’s a huge saving in time, time we can direct to writing more features, and deliver them to the customer.

Plus, tearing up that ransom note feels pretty good.

Image source: http://en.wikipedia.org/wiki/Villain