Tuesday, July 12, 2005
A debate with a co-worker.
When I came to work at Symantec I did so to learn how to work on big teams. And I'm realizing one of the lessons to learn is how to deal with people whose opinions are--well, "stupid" may be too strong a word. Perhaps a better term is "people I disagree with."
One of these disagreements stemmed around a debate as to the proper use of unit test code during the build process. This co-worker and friend of mine asserted that unit test code (that is, software designed to run during the build process to automatically test the validity of libraries within the code) should always run every time things build, even during the "edit/compile/debug" cycle of development.
(For those who may not know: the biggest activity that software developers do is the "edit/compile/debug" cycle. During this cycle you write a little code, compile it, then test and debug it to make sure it works. You never write working code the first time, so you wind up finding the bugs, editing the code to fix those bugs, compiling, and debugging--in a near endless loop. When things work well, a typical developer during an 8 hour day could do this activity some forty or fifty times.)
His assertion was that because the unit test code debugs the entire product automatically, that it is in fact part of the debug process, and is essential. My assertion is that the developer should be able to turn this debugging process off, so the code can be more quickly compiled. The faster it is to compile the code, the more times the developer can go through the "edit/compile/debug" cycle, the more productive the developer is.
Now his point wouldn't be half bad if it only takes a few minutes to run the unit test code. But for our product, it takes over a fucking hour to run all the unit test code. And there is no way to turn it off.
Which means that even the most intelligent and brightest developer in the world can only go through the edit/compile/debug cycle at most six times a day, rather than forty or fifty times. Furthermore, the developer can no longer "experiment", trying different things--because each time you want to "try" something, you pay a penalty of over an hour waiting for all the test code to run. And that assumes all of these unit test programs run correctly--and unfortunately we have a few poorly written unit tests that are subject to race conditions and can occassionally and randomly fail.
Have you heard of the chinese method of water torture? Where a drop of water pelts the victim for hours at a time--drip, drip, drip?
Our development environment, because we have to wait an hour to test some code, is the programmer's equivalent of chinese water torture. ¶ 4:58 PM
One of these disagreements stemmed around a debate as to the proper use of unit test code during the build process. This co-worker and friend of mine asserted that unit test code (that is, software designed to run during the build process to automatically test the validity of libraries within the code) should always run every time things build, even during the "edit/compile/debug" cycle of development.
(For those who may not know: the biggest activity that software developers do is the "edit/compile/debug" cycle. During this cycle you write a little code, compile it, then test and debug it to make sure it works. You never write working code the first time, so you wind up finding the bugs, editing the code to fix those bugs, compiling, and debugging--in a near endless loop. When things work well, a typical developer during an 8 hour day could do this activity some forty or fifty times.)
His assertion was that because the unit test code debugs the entire product automatically, that it is in fact part of the debug process, and is essential. My assertion is that the developer should be able to turn this debugging process off, so the code can be more quickly compiled. The faster it is to compile the code, the more times the developer can go through the "edit/compile/debug" cycle, the more productive the developer is.
Now his point wouldn't be half bad if it only takes a few minutes to run the unit test code. But for our product, it takes over a fucking hour to run all the unit test code. And there is no way to turn it off.
Which means that even the most intelligent and brightest developer in the world can only go through the edit/compile/debug cycle at most six times a day, rather than forty or fifty times. Furthermore, the developer can no longer "experiment", trying different things--because each time you want to "try" something, you pay a penalty of over an hour waiting for all the test code to run. And that assumes all of these unit test programs run correctly--and unfortunately we have a few poorly written unit tests that are subject to race conditions and can occassionally and randomly fail.
Have you heard of the chinese method of water torture? Where a drop of water pelts the victim for hours at a time--drip, drip, drip?
Our development environment, because we have to wait an hour to test some code, is the programmer's equivalent of chinese water torture. ¶ 4:58 PM
