Bill, Bill, Bill...
Epee Bill suggests that I have been too modest in describing my role in
the success of the Ann Arbor Duelist over the years:
Many of the "new techniques for getting lots better at things we thought were pretty darn good already" he mentions are pure Martin inventions that not only could not have been implemented better by anyone else in the club, but were actually imagined better than anyone else in the club by Martin.
Most clubs have a computer program that will seed pools and set match-ups. But only the AADS has one that also acts as a general ledger system for logging entry fee payments. It print receipts, too! Oh, and since we often have to collect money for people renewing their USFA membership, it handles that accounting as well.
I started to respond to his comment with a comment; but it got long enough and veered off into enough new topics that I felt it deserved a post of its own.
Bill, Bill, Bill... I thought I had you read
Fred Brooks. Apparently I have failed in your education.
In Mr. Brooks's famous essay, "No Silver Bullets", he argued that we'll see no more order-of-magnitude improvements in software development performance. He later concluded he may have been too pessimistic; but the core of his argument is sound.
That core rests on the difference between essence and accident. The essence of a problem is that part of the problem that
must be solved no matter what, because without the essence there is no problem. The accident of a problem is that part that only needs to be solved because of current circumstances, and would not be a problem under other circumstances.
Here's a quick example of essence vs. accident in my own past work. At one time, we needed a 3D histogram of colors in an image. In other words, how many pixels of black, how many pixels of white, how many pixels of a slightly off-white, and so on, and so on. Our color space had over 16 million possible colors; and the number of possible pixels was 200,000, which means you need four bytes to store a count. And that meant we needed 64 megabytes to store the histogram.
OK, try that again. This was 1990.
We needed 64 megabytes to store the histogram! In 1990,
nobody had 64 MB. That would've cost around $30,000. It simply couldn't be done.
So I had to devise ways to reduce the problem. In any given image, there were only 200,000 pixels; so even if every single pixel was a unique color from every other one, we only needed to count 200,000 possible colors, not 16 million. If we only knew which colors... Or we could lump really close colors together. Actually, I came up with a number of
really clever but difficult to maintain techniques for reducing this problem.
But today, I carry 64 MB in my pocket, and often forget I have it. It's a USB drive that Microsoft
gave away as a promotion for Tablet PC development. Today, I could solve the whole problem with these lines of code:
int[,,] counts = new int[256, 256, 256];
for(int y=0; y<img.Height; y++)
{
for(int x=0; x<img.Width; x++)
{
Color c = img.GetPixel(x, y);
counts[c.R, c.G, c.B]++;
}
}
That's it. Nine lines of code (counting curly brace lines) that I wrote in one minute. As opposed to thousands of lines that I spent months writing and fixing. Because "64 MB costs $30,000" was an accident of the circumstances of the time.
But the nine lines above are pure essence for this problem. No matter what else I do, if the problem is "create a histogram of colors in the image", then I
have to loop over the pixels in the image, I
have to get the color of each pixel, and I
have to increment counts. Those are the definition of making a histogram, its essence. Clever ways to trim down the count space are an accident, and I just wouldn't bother on a modern 2 GB machine.
So what does this have to do with Bill's comment? What's the point?
Is there a point? Do I
ever have a point? (Let's not talk about point control...)
Well, the point is this: while I am proud of our registration spreadsheet (which I should mention is based on an original design from Terry Krueger — I just added the automation), and I will concede that it has drastically sped up our registration
and our pool assignment and seeding (when we say fencing begins 15 minutes after close of registration, we mean it!), I contend that registration is largely accident when it comes to a fencing tournament. The essence is getting fencers onto strips and getting bouts fenced.
And the analogy to Mr. Brooks's essay is pretty close here, really. His argument was that early in the software development field, there was a lot of time spent on accident, such as sorting your punch cards when you dropped the deck (
everybody dropped a deck at least once), leaving relatively little time for essence; but as time went by and people devised better tools, the time spent on accident was drastically reduced. By reducing accident time, they drastically reduced the overall problem time. And his argument further said that we had reached a point where accident was a minority part of the effort spent on a problem; and that even if you could reduce the remaining accident time to zero, the reduction in the overall problem time would be small.
In a similar fashion, we've made most of the improvements we're able to make in registration.
The on-line pre-reg system is a Hail Mary attempt to make one more big cut in the registration time (and at that, it has been live for one whole day, and no one has signed up yet — tsk, tsk); but even if we were to reduce the registration time to zero (hmmm, embedded RFID tags in the fencers' bodies, reading a USFA database that automatically registers them, and then a voice-driven system that asks them what weapons they're fencing and then records the answer — nah, maybe next year), the time on the strip would still take up all of our spare time, and then some. We're right now running roughly five pools of seven. If merely five more people showed up, we could register those five more people in about an extra two minutes; but those five people would push us to pools of eight, increasing the number of pool bouts by fully one-third.
Nothing I could do on the registration side could change the fact that that would add around a half-hour to the schedule. Probably an hour, because we would probably see an increase in both foil and epee.
And as proud of I am of the registration system, it's only one area where we've made great strides in reducing the accident aspects. Somebody (I can't say
who) has worked hard to get us lots of cooperation and support from the venue. Somebody (I can't say
who) has gone out of her way to greet people at the door, guide them to their destination, stamp their hands, etc. (And she will be sorely missed this year. Geez, Bill, did you really need another kid?) Somebody at
the Division makes sure we have the strips and equipment well in advance. Somebody wheedles the directors into giving up a summer weekend. Somebody feeds the directors and keeps them happy and focused on the strip. The directors themselves know all sorts of tricks to keep things moving, and are happy to educate us on them. Somebody is on near-constant clean-up duty. Somebody organizes the troops to start tearing down strips as soon as logistically possible. And that last one is particularly telling, I believe: we're a highly disorganized, highly individualistic bunch with a fair amount of contempt for hierarchy and authority; and yet on the day of the Duelist, we
act like a disciplined military unit, with everyone knowing their parts and everyone doing their parts and everyone pitching in where needed and everyone working toward the shared goals of happy fencers and a timely tear-down. Nobody panics. Nobody plays prima donna or Napoleon. People who really don't get along all that well pretend for the moment that they're brothers in arms. And it's all so practiced and natural that you won't even notice it happening except in whatever small corner you inhabit. (Good grief, I only learned about the all-essential door greeter and guide last month.)
But as good as we've gotten at all of that, it's mostly accident and little essence. If we could reduce it all to zero time, we would still fill all available time with fencing. That's nothing to complain about, and I'm not complaining. I'm proud of what our tournament has become. But if we grew, say, 20%, we would have to really think about how to meet our schedule.
Whereas if we could come up with
one more qualified director and
one more strip, it would cut out a half hour each from foil and epee. Two more strips would probably cut an hour each. Since I doubt we'd want to go smaller than pools of five, two more strips would be ideal. And that would do more for the schedule than anything I could do with software.
Of course,
we know where that would lead...
