Saturday, December 20, 2003

Smells Like Teen Spirit

A couple of recent posts have reminded me of one of my rules of thumb - developers who spend too much time on the debugger are not good developers and should be rolled off my team.

Keith Ray writes in Cost of Debugging quoting Christian Sepulveda,

One half of each day was completely wasted. The developer couldn’t really doing anything productive during the four-minute debug cycle because he had to navigate to the correct place in the application and execute the right steps so he could observe the results of the change he just made; he was forced into tedium. In other words, half the development budget was being spent on performing repeated, monotonous tasks. This isn’t a very effective use of resources or talent.

It was my former mentor Duncan Smeed who pointed at Robert C. Martin’s Debuggers are a Wasteful Timesink, which took me back to experiences as a contractor working at IBM’s PC Company and my earlier roots as a machine code programmer in the games industry in the early 1980’s. [Aside: In fact if you ever owned a Sinclair/Timex Spectrum there is a strong chance you owned and played one of my games.]

In a world where programmers are measured by activity and dedication to “activity” then they get rewarded for spending hours on the debugger. I can specifically recall one developer who was earning almost twice as much as me to sit and play with the debugger until 9pm every night when I was going home at 3.36pm (the earliest available moment under the flexitime rules). Why did I go home so early? I had finished my code and it was tested and working.

In the 1980’s, we didn’t really have debuggers and when we did they were useless because we were testing real-time performance and so much was running off timers and interrupt driven. It just wasn’t possible to test with a debugger. It was time wasting and useless. I learned to code by putting logging and instrumentation into my code. I learned to develop by small increments fully unit tested. And the biggest lesson I ever learned when working as a team is - you agree the interface (the method signatures) at design time and you b****y well stick to them. With assembly language, the concept of “breaking the build” blows the machine up - and in those days we didn’t have multi-process spaces to protect the memory and keep the machine alive.

The smell of an over-revving debugger resembles the teen spirit which encourages idle youth to spin tires with the parking break on. It makes a lot of noise, it creates smoke, it provides an illusion of activity and intelligence, but ultimately the velocity is zero.

[Updated 12/21 1300hrs PST]