Agile Zone is brought to you in partnership with:

Gil Zilberfeld has been in software since childhood, writing BASIC programs on his trusty Sinclair ZX81. With more than twenty years of developing commercial software, he has vast experience in software methodology and practices. Gil is an agile consultant, applying agile principles over the last decade. From automated testing to exploratory testing, design practices to team collaboration, scrum to kanban, and lean startup methods – he’s done it all. He is still learning from his successes and failures. Gil speaks frequently in international conferences about unit testing, TDD, agile practices and communication. He is the author of "Everyday Unit Testing", blogs at http://www.gilzilberfeld.com and in his spare time he shoots zombies, for fun. Gil is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

The Invisible Time Sink

06.09.2013
| 2904 views |
  • submit to reddit

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.

PS: I’m going to talk about Coverage, another suspicious metric at DevCon TLV and in a Typemock webinar this month. Your invited.

Published at DZone with permission of Gil Zilberfeld, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Loren Kratzke replied on Mon, 2013/06/10 - 1:09pm

 I do not believe there is any single proper ratio, let alone 60/40.

And just because software has tests does not by any stretch of the imagination mean that the software has no bugs. Tests validate a predicted outcome. They say nothing about whether the outcome is beneficial or detrimental to the goal.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.