The Invisible Time Sink
I’ve recently watched a session called “Chasing the golden GOOS”. From the cunning name, you probably get that it’s about developing an app using the “Growing Object Oriented Systems Guided by Tests” approach. The whole thing was interesting, and then there was a question in the end. Someone in the audience asked about the ratio of production code and tests. The answer was 60% tests and 40% code. These kind of numbers are not rare in TDD land, but regular folks say “WHAAAAT?”
Why is that?
The Illusion of Productivity Improvement
We’re always on the lookout for metrics , so we can improve our delivery pace. Take for example keyboard shortcuts. In the last 20 years we’ve had better IDEs and tools, all relying on shortcuts to make the things we do faster. Computers are quick, and to keep up, you’ll use the keyboard instead of the mouse. No self respecting developer uses a mouse, right?
It makes a lot of sense, then, that if a task is about 20K lines of code, we can get it faster to the finish line if we just used the keyboard! Apply these to all kinds of productivity tools, and you’ve got it down from 1 month to a week!
The only problem with this calculation is that it’s wrong.
Most of the time of development is not about using the computer. It’s about using your brain. While productivity tools shorten the typing time, the rest cannot be minimized so easily. We based the calculation on an assumption that we write “working software”. If it works we can improve the time to write. Every manager hiring a developer believes that (although reality has shown us time and again we’re wrong). Sure, bugs are part of the code, but just a small part. But did you measure how much time you’re thinking about those pesky bugs? The fix maybe a couple of lines, which took you three days to arrive at.
This is the black hole of development: It swallows time, never to be seen again. Or remembered in the next task.
Time Well Spent
Back to our story. Why does the 60% “extra” code appear wasteful? Because MY developer can just write the 40% of production code!
But do those 40% work as you click them away on your keyboard? Ay, there’s the rub. Assuming we want to get to those 40% working without tests, there’s going to be time and pain (in form of bugs) involved. It maybe that even at the same length it took these guys to write the 100%, and we still won’t know if we did a good job. But those guys know they have working software, because they have tests to prove it.
In other words: 60% test code is not waste. It’s a 100% working code. That’s the task, and it was delivered.
And the next time someone tells you he can do these tasks without the tests at half the time, pull out your stop-watch.
Shine a light on that invisible time.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)