We sometimes tend to get a little wrapped up in the jargon of
our trade: process frameworks, iterative development, and the like.
What would happen if we had to explain this stuff to "civilians"?
This month we meet one such candidate: Roscoe Leroy.
The first thing to know about Roscoe is this: Don't make fun of his name. "It shows my parents had a sense of humor. Besides," he always adds, "it could have been worse. They could have named me Leroy Leroy."
Roscoe, it turns out, is an old war buddy of my dad's. According to Roscoe, they both served under Patton, although my guess is that my dad served directly under Roscoe, and Roscoe served somewhat remotely under Patton. Mr. Leroy (one never calls him that) is one of those old salty dogs who has an opinion on just about everything. The annoying thing is that he is right so much of the time.
Of course, when he is wrong, the results are not pretty, because he is willing to back his convictions to the hilt. I have seen Roscoe push all his chips to the center of the table, confident that his poker hand was the best. The results were spectacular, but not always in the way Roscoe would have liked.
On the plus side, Roscoe's wisdom is simple and easy to understand. It comes in the form of very prescriptive advice. So long as you don't probe too much for deep theory, you'll be fine. Going with Roscoe is a leap of faith, one that we might all benefit from taking when the chips are down.
Roscoe has been there and done that. He boasts of having finished the eighth grade, but I have it on good authority that he graduated from an excellent high school some time in the thirties. My dad explained this discrepancy to me simply by saying that Roscoe felt it unnecessary to flaunt his education.
At various times, Roscoe has served in the military, fought oil well fires with Boots and Coots, 1 and been a mining engineer. Those experiences made him a pragmatic kind of guy, but they also taught him how to perform under pressure. He does manage to get all the dirt out from under his fingernails if you invite him to dinner, but don't expect too much use of the salad fork.
Roscoe doesn't do math, really; he does arithmetic. Answers tend to come out of his mouth in whole numbers. When asked about this, his reply is along the lines of, "Well, it always comes down to how many sticks of dynamite you need to make the hole, and how many men you need to clean it up. I don't cut my dynamite in half, and I don't hire fractional people." When he puts it like that, you know you are done.
Roscoe showed up at my house a while back with a copy of USA Today under his arm. "Looks like even McPaper is starting to understand," he said, knowing I would be unable to resist taking the bait. When I asked him what he was talking about, he showed me one of the little squibs in the corner of the page: 52 percent of the population prefers vanilla ice cream, 48 percent chocolate. From my perspective, that registered pretty high on the "so what?" meter.
Then Roscoe offered the following. "Notice what it says below the little bar graph: Accuracy 2 is plus or minus three percent. Now that is significant. For years they published these factoids without any indication of the error bars. We must be getting less stupid about polls, if they think they have to tell you the likely error."
I had to admit I had never thought about it that way. I also was intrigued by why Roscoe thought it was interesting.
"Of course," he said, "three percent error is important, because the total spread in the preference is only four percent. So we can't be really sure. But I'll tell you one thing: I bet I know how many people they asked."
Certain that Roscoe had never taken a probability and statistics "seminar" that didn't involve poker chips, I was about to learn otherwise.
"Here's my guess," he continued. "They talked to about a thousand people. The error on a thousand answers is roughly the square root of a thousand, which is 31.4. Thirty one over one thousand is 3.1 percent, which of course is roughly three percent."
"Wait a minute, Roscoe," I jumped in. "The square root of a thousand is 31.6, not 31.4."
"There you go, letting your education get in the way again. Any fool can remember that the square root of ten is pi, which is 3.14. For a thousand, move the decimal point one place in the answer: 31.4, done deal."
Well, my math was more accurate, but seeing as how we were going to round off anyway, the difference did seem academic. And it did seem like a fairly reasonable calculation.
"I'll tell you another thing," Roscoe continued. "You'll never see that kind of squib with an error bar of, say, one percent."
I thought about that for a couple of seconds, but Roscoe wasn't patient enough to wait for my thoughts on the subject.
"Doesn't take an Einstein to figure out why, either. If you use the same logic, you'll see that they have to talk to ten thousand people to get the error down to 100, or 1 percent. That's ten times as expensive as talking to a thousand people. So to push the error down from 3 percent to 1 percent, it costs you an incremental factor of nine."
"Ten," I thought to myself. Then I realized you could reuse the first thousand in the second sample. Never misses a trick, that Roscoe.
By now I had developed a belief that Roscoe had learned about square roots. This was confirmed when I talked with him about projects and schedules. His assumptions about the number of weeks in various periods was, well, curious. The following table encapsulates my discovery.
| Duration | Roscoe's Duration |
| Two years | 100 weeks |
| One year | 49 weeks |
| Nine months | 36 weeks |
| Six months | 25 weeks |
| Four months | 16 weeks |
| Two months | 9 weeks |
| One month | 4 weeks |
When I asked him about three-month projects, Roscoe replied, "Don't like to do those."
It was clear from these numbers that some Leroy square root arithmetic was in the offing. You don't set out a pattern like that without some underlying motivation. Another thing that was interesting was Roscoe's unwillingness to talk about time intervals of less than a week. "We ain't day laborers, son," he'd say. "I pay my engineers by the week. So that's the smallest interval I ever use when estimating."
Seemed about as reasonable as his argument about fractional people.
"Actually," said Roscoe, "I can compute square roots lickity-split. And without a square root button on the old calculator."
"Fifty-three!" I shouted out, challenging him on the spot.
"No sweat," he said, talking and punching numbers simultaneously. "Fifty-three is close to forty-nine, so we'll start with a guess of seven. Seven into fifty-three goes 7.57 times. Now we know that since seven is too low, 7.57 must be too high, so let's take the average. In my head, that's 7.28. Then, 7.28 into 53 goes, well, gosh, would you believe it, 7.28 times. So I guess the answer must be 7.28."
For the guy to have extracted the square root to two decimal places with two divisions was impressive. But Roscoe had a different point of view.
"Too tiring," he said. "Prefer to work with round numbers. Sticks of dynamite and whole people."
Just when I thought the world was safe, Roscoe fessed up. "They closed the mine, son," he said. "Looks like I need to find a new job. Think I could manage one of those software projects?"
Thank heavens the dot com frenzy has abated, I thought. How the hell would I ever explain that to him? On the other hand, he would certainly bring a fresh point of view to our business. We might actually learn something in the process.
"Sure, Roscoe," I replied. "Go off and learn about iterative development. That's the best place to start. Read up on that, talk to some people, and then come back to see me." I figured that would keep him busy for a while.
"I'll get back to you," he said, being careful not to let the screen door slam as he left.
About a month later, Roscoe showed up as usual, with no notice and a chip on his shoulder. I figured he had had enough time to understand the essentials, and I was interested in what he had to say.
"Well, there sure seems to be enough written about this stuff," Roscoe opined as he pulled up a three-legged stool. "In fact, it's amazing to me that you could know so much about something so screwed up."
I allowed that our success rate in software projects was not quite up there in the spectacular category. Roscoe was unimpressed.
"Seems like folks think this stuff is really hard. Shoot! Digging for coal is hard. This is just software, after all."
I said, well maybe we should use the word "difficult," not "hard," but Roscoe was not to be convinced.
"Hate to remind you, but the Egyptians built the pyramids. 'Course, they did have that fella Euclid 3 , who was nobody's fool. But, even today, the Amish can put up a barn in one day, for crying out loud."
"But," he continued, "there are some signs of hope."
"It strikes me that the iterative development boys are on the right track. Although it's just a fancy name for what every cowboy carpenter 4 does -- cut and try. Those boys know that they can't measure or cut that accurately, so they rough it out first, and then fix it until they're done. Of course you guys would call it 'successive refinement on subsequent iterations.'"
I detected a small note of sarcasm in Roscoe's summary. But he was not to be deterred.
"Of course, the cowboy carpenter has to be more careful than you guys. He knows that he can always take a little more off, but adding material back is hard. Learned that from his barber. So he always has to make his first cut the right way. Some big city comptrollers use that algorithm, too."
Now Roscoe always pronounces the "p" in comptroller so that you know that he knows the right word. But "algorithm" came out of his mouth sort of like "I'll-go-rhythm." Oh shoot, I thought. We are in big trouble. Roscoe has learned a new word.
"Roscoe, where did you pick up that word, 'algorithm'?" I asked.
"Well, son, I've been talking to some software architects." he trailed off.
"Huh," I replied, "who told you to do that?"
"First of all, you did. You said talk with people. Hey, I may look stupid, but I know what I don't know. There's a big difference between reading a set of blueprints and producing one. So I went and palavered a bit with those good old boys."
"Fair enough," I said. "What did you learn?"
"Well, it makes sense to me. Basically, when you start a project you don't know spit, so the initial phases are important. After all, you don't want to build a fifty-dollar fence to keep in a ten-dollar horse, so understanding what it is you're trying to do just makes sense to me. Likewise, I like the idea of keeping the payroll down until you have a pretty good idea of what all those people are going to do. Otherwise, you're just paying them to chew tobacco until someone figures out what they should be doing."
I was starting to be impressed with Roscoe's appreciation of the situation.
"Then I got into the scheduling and estimating end of things. Some pretty smart fellas there. In particular, that guy Barry Boehm and that guy Walker Royce seem to have a handle on some of it. Although their Coconut model is a little high falutin' for me."
I cringed, but didn't have the heart to correct him. COCOMO and coconut do sound a little alike, after all. And there were lots of other interpretations you had to make in parsing Roscoe-speak, so this would not be too much of an additional stretch.
"Then I got around to reading some Kruchten and Booch, and even stumbled onto your name. Right here," he said, pointing to a page in a dog-eared copy of Grady's book, Object Solutions. 5
Sure enough, he had me dead to rights. There I was, in black and white, in a footnote on page 136.
"Well, it says here that you and that Kruchten fella have observed that the duration of an iteration in weeks seems to be equal to the square root of the size of the code to be developed, as measured in thousands of lines of code."
It was hard to argue with him. It was a direct quote. I figured I was in for it now.
"Hmm. I even talked with my architect friend, and he said there's a term for 'a thousand lines of code.' Claims it's called a KSLOC, for 'kilo source lines of code.' Whoosh!"
Roscoe was clearly warming to the task.
"Buncha B.S., I'd say. Like trying to estimate how big a project the pyramids are going to be, and using the 'brick' as your unit of measure. Only that would be ridiculous, so you invent the 'kilobrick.' Dumbest thing I ever heard of."
The man was gaining momentum, and I was not going to lie down in front of that locomotive just yet.
"But the real problem, as I discovered in talking with my architect friend, is that nobody knows how to count SLOCs or KSLOCs. Do you count every line, including comments? Do you count your headers and your source files, where there is obviously lots of repeated stuff? And how do you deal with those huge libraries that you're gonna use, but not write from scratch? Basically, you have a number that you can get from 'Dial-a-Prayer.'"
I made a note to talk to the architect about telling Roscoe about headers and such. I knew he didn't make that up on his own. But the man had a point: We had concocted a formula that was based on a number that was, to put it charitably, subject to some interpretation. The prediction would be no better than the definition we used for SLOCs.
Guess We Did Something Right, Part Two
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 porridge -- it 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's 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."
I was not surprised to see Roscoe's calendar make a guest appearance. Nor was his fondness for square roots absent from the proceedings.
| Duration | Roscoe's Duration | Iteration Length | Number of Iterations |
| Two years | 100 weeks | 10 weeks | 10 |
| One year | 49 weeks | 7 weeks | 7 |
| Nine months | 36 weeks | 6 weeks | 6 |
| Six months | 25 weeks | 5 weeks | 5 |
| Four months | 16 weeks | 4 weeks | 4 |
| Two months | 9 weeks | 3 weeks | 3 |
| One month | 4 weeks | 2 weeks | 2 |
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.
Roscoe Admitted to SPM 6 Fraternity
Based on this little exercise in figuring out how long an iteration should be, I deemed Roscoe competent enough to take on his first iterative development project. But I had a warning for him.
"Roscoe, listen up," I said. "You are going to find out that 'calling the shot' in software projects is incredibly slippery. If you come up with any ideas there, I'd be really glad to hear from you."
"Sure 'nuff," he said. "See you next month."
Editor's Note: Look for more wisdom from Roscoe Leroy in our February issue!
1
Boots and Coots used to be a
colorful oil well firefighting outfit. Some time ago, while I was
not paying attention, they "went legit." See http://www.halliburton.com
2
Sometimes the term precision is used
instead, but precision and accuracy are not the same.
Precision indicates the degree to which the measurement is
reproducible. If you have a high precision measurement method and
measure many times, most of the measurements will fall within narrow
margins. On the other hand, accuracy is a measure of how
close the measurement is to reality. Precision talks about measurements
on the sample; accuracy reflects how close your measurement of the
sample is to defining the properties of, in this case, the underlying
population. Roscoe may appear to be sloppy in his use of these terms,
but he is not; we shouldn't be either. Shooting for high precision
is silly in the face of low accuracy, because high precision costs
money, and we should never pay lots of money for an inaccurate result.
Just remember, always, that high precision does not necessarily
imply high accuracy.
3
A good example of Roscoe not letting his education
get in the way: Euclid came after the pyramids, by a lot. He lived
around 300 B.C., and the pyramids were built circa 3000 B.C. Makes
the pyramids seem even more impressive, doesn't it?
4
What Leroy is referring to here is the kind
of carpentry ranchers and farmers do -- building rough structures
like barns and fences. The other end of the spectrum would be fine
craftsmanship, as exhibited by a professional woodworker or cabinetmaker.
5
Grady Booch, Object Solutions: Managing the
Object-Oriented Project. Addison-Wesley, 1995.
6
Software Project Manager
Recently appointed CEO of Ravenflow, an Emeryville, California-based company delivering precision requirements validation for software developers, Joe Marasco served as senior vice president and business unit manager for Rational Software prior to the company's acquisition by IBM. He held numerous positions of responsibility in marketing, development, and the field sales organization, overseeing initiatives for Apex and Visual Modeler for Microsoft Visual Studio. After retiring from Rational in 2003, he published The Software Development Edge, a collection of his essays on software project management originally published in The Rational Edge. He holds a Ph.D. in physics from the University of Geneva, Switzerland, and an M.B.A. from the University of California, Irvine.
Comments (Undergoing maintenance)
Table of contents
- Roscoe Arrives on the Scene
- Roscoe's Qualifications
- Chocolate Versus Vanilla
- Roscoe Explains
- Roscoe Goes Deeper
- Roscoe's Calendar
- Roscoe Computes
- Roscoe Gets into Software
- Roscoe Reports In
- Guess We Did Something Right
- Roscoe Sums It Up
- Roscoe Picks a Bone
- Guess We Did Something Right, Part Two
- Roscoe Admitted to SPM 6 Fraternity
- Notes
- About the author
- Comments
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
