Just when I thought Roscoe was going to write me off completely, though, he came up with a compliment, sort of.
"You did get something right, Joe. The square root is the key. The whole idea is that you don't want to have too many iterations, because each beginning and end of an iteration has overhead, which as we all know is just plain unproductive. On the other hand, you don't want to have too few iterations, because then you lose all the benefits of iterative development. It's like Goldilocks and the porridgeit needs to be just right.
"Now, I think you were right to peg the iteration length to the square root of the size of the project. And picking the week as the unit of measure was surely the right thing to do, as it is the fundamental unit of labor measurement. All you did wrong was get tangled up with that KSLOC idea. I've got a much simpler way to do it."
I listened. Carefully.
"The main problem is that you start from the wrong place. You need to use that Coconut or some other technique to negotiate the total time you are going to be allowed to have to complete the project. Management always wants it sooner, and you'll always wind up discussing a date, not the number of lines of code. You might get to barter the date against the size of the team, or against the feature set, for instance, but in the end what you will have that is fixed is the length of time.
"Once that's settled, it's easy. The duration of an iteration should just be the square root of the total duration of the project. Let me show you this little table I made up." With that he whipped out Table 10.2.
I was not surprised to see Roscoe's calendar make a guest appearance. Nor was his fondness for square roots absent from the proceedings.
Damn! Wouldn't you know it, when I went back and checked against my database of projects, Roscoe's estimates weren't that far off. As he would say, "Plus or minus one stick of dynamite."
And no SLOCs. I was impressed.