Software Mayhem

The process of releasing changes to a piece of software got a lot easier with the advent of the web-driven application.   Time was, you had to build a new version of an application, and then go through a tortured rigamarole process of releasing a new version and watching as lots of old dinosaurs ignored the release and continued to bitch about the bugs you fixed in it.   Or worse, they instead downloaded and installed the upgrade, but some pecularity of their computing setup that you didn’t test for got in the way, and it explodes, taking all the user’s data with it.

And the answer to “Did you take a backup?” in such situations is always “Uh, no, was I supposed to?”

Sadly, you can’t test for everything, no matter how much you try.   The smoothest upgrades for software usually happen when the authors have found a way to reduce the number of tests needed, rather than conducting more of them; Mac OS X’s applications these days are largely self contained bundles, where you toss the old one and copy the new one into place.   So it’s not really an upgrade so much as a brand new install that shares a few settings.

Web applications follow a different logic.   It’s one of the reasons I designed tabroom.com to run off the web; I can change a single code file on the server, and it changes everywhere for everyone.   This model has a lot of advantages; I don’t have to worry about installers, about operating systems, about anything on your computer; as long as you have a browser (preferably not Internet Explorer, by the way), you have full access to all its features.

However, that leads to fun and games whenever I roll out a new feature or new toys or something.   This summer one of the big changes I made was a significantly revamped housing interface; I threw it together two years ago for the Lexington tournament, and I hadn’t really had a lot of time to put it together at the time.   So I cobbled together barely-good-enough and left it at that.   This August, instead, I ripped the whole thing out and built it mostly the right way, and it’s been working pretty well since then.

However, there are two bits of any piece of software that can be…exciting.   First is the software itself; it has to play it’s own game the right way.   The second, and more dangerous, is how well it plays well with others.   The interface between one part of software and another is the danger zone; the housing system could work perfectly, but it might screw up the calculation of judging obligations (another part of the software I overhauled over the summer), or the waitlist mechanism, or lord knows what else.     Some baroque combination of settings and tribulations might break something at any minute.   It’s very difficult to test for every such combination; and since I’m flying solo on this effort and have limited time to dedicate to it, it’s impossible for me to do so.

Over time, a software develops “maturity”.   The edge cases are found, the weirder bugs are teased out, and the complexity of the software settles into a known working state where the expected happens more and more often the more it is used.   That takes a few times and a few trials, and large portions of the software have resolved into exactly that role.   I launched the system in Kentucky this year, after MA and Jersey and various others have used it for years — they used the simple expediency of “asking.”   So far it’s going well; a few bumps, but nothing huge.   What’s great is that I know a few different ideas and ways of running tournaments now, which is helpful knowledge indeed for a local league leader like myself.

Housing and the stuff Menick is using hasn’t 100% yet, but we’re getting there.   I think next year during Bump I’ll hear from him maybe a quarter as often.   It may be sooner, but he hasn’t yet figured out how to turn off the “Break Randomly” setting that I’ve set on his user account.   I can’t wait to see the look on his face when he tries to export the divisions into TRPC.

The next tasks are speeding things up a little bit; I substantially cut down the disaster checking time last week.   I also made the printouts a little better.   But most of all, the advent of the “just do everything the way I want it done” button is just f’n wonderful.   It took me a while to get all the ducks in a row where that could work, but now it does and it’s lovely.

The next two big projects are at the behest of competing communities; first is programming in support for NFL Districts, which would please the Joyless crowd including the Reverend B.A. and my local folks.   I’ve never used Joy so I can’t comment on it too much, but the price tag is daunting if nothing else, and I strongly believe that participation in forensics should not be extractive.   A lot of adults go into forensics looking for something; for most it’s the ego boost of winning something, however vicariously, which depending on how far its taken can be healthy or not; extracting money from a largely impoverished activity distorts the world in a way my socialist soul dislikes.   I don’t accept money for tabroom.com, both because of that belief, and because if people paid me then I’d have obligations towards them, and that would make for a much worse dynamic.

Second is Debate support.   TRPC is a very handy program, and I can make it do most of what I need, but it does have quite a few warts, and the largest is that it’s not very easily learned; I have a very hard time training people up into using it.   It also resists certain things, and makes putting things together manually difficult, which is a shame, since it requires manual intervention so frequently.   I also don’t like it how only one set of data entry can be happening at once; tabroom lets you enter indiscrimiately from multple stations.   Mostly, though, Microsoft has entered into an era of rapidly changing APIs and programmatic requirements, and TRPC is programmed in an archaic runtime language that might not be supported for very much longer; I worry for the day when it no longer runs on anything but the “ol’ bessie” Windows XP computer in the corner; inevitably some future Yalie will try to check his email on it and spill a can of coke in it, and then we’ll be back to tabbing on cards before we know what happened.

And I’m sure when I do either one, something will break.   Hopefully not much though.   I am getting better at this.   Even I flinch when I find some early code of mine embedded in the system.