April 1, 2008

...Learn TDD with Codemanship

The Future Of TDD - Real-Time Feedback As You Type?

On my way back from lunch today, I was walking down the stairs when I heard a loud "thwack" and turned round to see that my security pass had come loose from its clip and fallen to the floor.

The stairwell is quiet, and sounds reverberate off the shiny, hard concrete surfaces, which has the effect of amplifying them.

If I had dropped my pass in the street outside the building, I might not have heard it hit the ground. And I might have gone blissfully on my way, until I had to get back into the building and found myself without the necessary token of identification.

Which would have been very inconvenient. If I didn't hear my pass fall to the floor, then I wouldn't have had anything more than a very vague idea of where it might have fallen. I might have had to spend a lot of my very valuable time retracing my steps. It could have dropped anywhere between the staff restaurant and my office 300m away - with a busy road along the way. That's a lot of ground to cover.

All in all, when something goes wrong, it's better to have your attention drawn to it straight away. And the same is true of many other kinds of problem. Take bugs, for example. When we drop a bug into our code, it makes no sound, and so we don't notice it's happened until potentially much, much later when it manifests itself to testers or users. By which time, we have only the vaguest idea of where the actual bug might be in the code. It could be anywhere between the button click and the database, and that's a lot of ground to cover, too.

Ideally, when we introduce a bug, or a code smell, into our code, there ought to be a loud "thwack" as soon as it hits the code that draws our attention to it.

Back in the days when programmers wrote code on papyrus, we used to have an even bigger problem, in that our code wasn't syntax-checked as we typed it (indeed, mainframe programmers might recall the days when you had to wait hours for the results of a syntax check!) Making a simple 100-line program compile, let alone do what it's supposed to, took a lot of extra work. But now most development environments compile on-the-fly and highlight any problems literally as we type the code. There's no doubt whatsoever that realtime syntax checking has had a profound impact on developer productivity.

In years to come, I hope we'll see on-the-fly semantic checking - i.e., functional testing - happening literally as we write the code. That's no short order computationally. The kind of syntax checking we get now from Eclipse, Visual Studio and their like required hardware platforms to reach a level of performance where that could be done in the background in real time. The kind of computational power we might need to run a comprehensive suite of functional tests (e.g., JUnit tests) in the background as the code is being typed* - well, that's probably an order of magnitude beyond what we can do today on our desktops. (Of course, we could come up with some clever shortcuts, like only testing directly or indirectly dependent code, but the overhead would still be significant.)

If it currently takes 5 minutes to run your unit tests, we might need to get that down to a few seconds - maybe less - to make it usable (lest we have to tolerate an annoying lag between typing and feedback).

Let's say we want to slash 5 minutes down to 0.5 seconds. If Moore's Law holds, desktop computers that powerful might be about 10 years hence.

Now it might be model checking instead of unit testing - or a combination of various testing techniques - but I think it will come in some form. It has to. I need to hear that "thwack" if I really want to take my productivity to the next level as a developer.

Same goes for code smells. Real time static analysis of code as it's being typed is something I've touted to whomever will listen in the past few years. The tools exist, just as they do for functional testing. But, again, I suspect the computational overhead will mean that this, too, is a decade away from becoming a reality.

In the meantime, 5 minutes is a mile better than 5 hours, or 5 days, or 5 weeks. The feedback loop is definitely shrinking, and I wouldn't be at all surprised if our productivity and the resulting code quality is gradually improving with each incremental reduction in time.

And while I remember, note to self: sticky tape on pass clip.



* OK, so there would need to be some delay as the code went through phases of being temporarily non-compiling to being temporarily compiled.



Posted 10 years, 5 months ago on April 1, 2008