Eating our own Cooking

I have long felt that for us to really achieve progress with our efforts, we need to be using it regularly. Eat our own cooking, as they say.

Essentially, what this means is that we as a project need to make ourselves totally and fundamentally dependant on older versions of our own software.

What does this mean? By "totally" I mean as a group, we as a project need to put ourselves in a position such that each and every single one of us has to use our code regularly - weekly at least. By "fundamentally dependant" I mean it needs to be something important that will be extremely frustrating if it doesn't work; more than just a test, but something that wraps itself around our vital core.

Maybe you think this is a strange stance to take, but we know it works because we did this with STAGE last year, and it worked very well. Even though STAGE was buggy and we didn't really have a client, we went ahead and held all of our design meetings on it. At first it really sucked, and it crashed or locked up regularly. But this gave us a wonderful itch to scratch, and everyone dug in to finding ways to make the system more stable, and it encouraged many client developers to find ways to make their clients work with STAGE. The amount of progress made by WorldForge each week was astounding; within two months we could pretty much use STAGE and Silence-py in the same manner as IRC.

Note that above I also said "older versions of our software". Why older? Clearly there's an advantage in being able to test the latest and greatest, right? Well, yes, but there's a serious price, and one we oft paid with STAGE. The temptation to get your latest code changes in and see them in use is quite strong, and for a developer can be overwhelming. However, for folks not intimately involved in the development work, this can spell frustration. Frustrated people will eventually give up and go back to IRC, thus spoiling everything achieved. Thus, I feel that for this development strategy to work, it is critical to institute a process whereby the developers formally deliver fixed code releases, which can be downloaded, tested, and installed by system admins. If testing did not work sufficiently successfully, then that release would not be installed for use. Obviously, a lot of work would need to be done to ensure each release is solid, however it's still important to cut releases quite often; otherwise we lose the rapid feedback that developers thrive on (who wants to wait 6 weeks to see the benefit of their bug fix, after all?)

Perhaps you're thinking to yourself, "But this whole idea sucks because xyz doesn't work on whatever system I happen to be stuck on." You've grown accustom to features in your IRC client. Maybe you just love its stability. Maybe you found a client that doesn't use too much resources, or that is easily hidden amongst your work terminals. Wink But all of these types of arguments are just begging the question, "Shouldn't our software be able to fulfil those needs too? And how are we possibly going to know which of those issues we need to fix until we start using the software in these ways?" Also, it was my experience that this challenge really brought out the best in our client coders; Demitar, for instance, was able to get Silence-Py to a point that I felt I had all the ircishness I wanted, within a couple months.

Some of you may be thinking, "But xyz is a bear to get compiled, and I don't think I can do it." But this is the root of the issue, and it's a real chicken-and-the-egg kind of problem. Until the code is solid, there won't be users, true, but until there are a lot of users, what motivation do developers have to solidify it? Trust me, the reality of hundreds of people trying to use a given client will put a very strong itch in place to get that client to be easy to install. Imagine the pride you'd feel if you figured out the solution to a nigglesome bug that was preventing scores of users from being able to try out the software?

Anyway, here's what I'm advocating: First let's get a copy of Cyphesis-C++ stably running Acorn and ensure we have binaries of UClient to go with it, and then turn responsibility of maintaining this software over to a couple sysadmins (preferrably folks who have no involvement in Cyphesis or UClient development), and charge them with keeping that service running solidly and reliably. The same will also be done with STAGE and one or more clients. Then, let's institutionalize use of Request Tracker for filing problems with them, and make it easy and clear for new users to submit bug reports, so that our developers get clear feedback about the problems, and so they have a reliable place to look for tasks needing to be done. Next, let's push each of our teams to start holding their development meetings on STAGE instead of on IRC or the mailing lists. Finally, let's think about continuing our old Friday night tradition of playing our games as a group: Acorn, Werewolf, general purpose roleplaying, and hopefully some elements of Mason too, before too long!