Q. What did we fail at? This article is missing context.
There were three issues: -Communication -Time -Tools
Our communication went through email, IRC, wiki, CVS revision info and code coments. It was pervasive but had little cohesion. In IRC we had many important discussions, but as we kept no logs, people lost them when they were off-line. Our design ideas were scattered among these media, it was very difficult to pick them and have a clear idea about the overall status. We developed two solutions in parallel, but if we had better communication I think we could have only one, instead of two to test which was better later. I believe a centralized tool would be better to deal with these issues and feed information to people.
From GMT+3 (NicTiger?) to GMT-8 (BurtonRadons) we always had someone sleepy if everyone was together (IIRC we were together in IRC only once). Between work (on monday), sleep and personal business we had few windows to get two or three people together. Most of the time we were working solo, using IRC to ask questions only, and leaving notes to everyone before going to sleep. It's difficult to handle with this problem, it doesn't have a simple solution. Also we lost the opportunity of meeting at the start of contest (I've joined them later) to discuss the main problem before trying to code a solution.
CVS is good to keep a unified source of code, but it requires much tinkering (administration and explicit synchronization/merging) to deal with quick coding. A tool with file locks would be better, also we could use some form of instant messaging telling us to update. The dmd 0.67 compiler is nice, but it still surprised us from time to time. Bugs were sparse but they existed. Also dealing with modules in multiple directories is a PITA. There are few libraries available, poorly documented (Dig is an exception). With better libraries, both standard and open-source, our job would be easier. Being able to express the problems directly is very good, instead we developed five diferent point abstractions (in some kind of way), sometimes embedded in other types, sometimes a type on it's own. A good thing is that the vectorization code we developed can be used to design a good open-source library. Our build management tools, make and digc, aren't ideal to make general scripts, so they were used to compile and run, but not to compile and test, compile and build library, generate documentation, etc., so most of our tasks were manual instead. We still need some kind of DUnit; to do proper unit-tests, with reporting, resources management and partial test execution.
The conclusion is: if we had more reliable and comprehensive tools, better communications and more time (not over the contest period, but time available) we would've finished the contest, and perhaps get ourselves a nice place (top 20 maybe?). We had the skills necessary, not the experience to know how to solve problems fast in this kind of situation. Next year well do better.