If you wake up on a Saturday at 4pm and wonder why it’s getting dark (or rather, why it’s already so bright outside at 4am…), then you know you must have had a fun 24h hackathon behind you!
Usually the “team building” events in my office involve beer and outdoor sports, but since they try to appeal to everyone’s tastes, the winter team building event was a 24h battle of programming wits, free pizza and energy drinks included.
Nine teams with 3-4 members each signed up for this game that started on Thursday at 5pm and ended on Friday at 5pm. (Members of one team were pulled out for a P1 support issue, but they solved it within 2h, so they returned and their team got an extra hour, which is fair.) Every team had one meeting room reserved, and we were allowed to use the internet (including open-source software or public libraries). Every team got a shared drive, and had to upload the sources, executables, and final presentation, by 5pm to participate in the contest to win a prize (I’m not saying what the prize will be, but I’ll hint that it had a flat, rounded rectangle shape and its name started with a small “i”).
As in every team game, success and failure depends on the composition of your team. We got along perfectly personality-wise, but my team was a bit handicapped on the technical side: Many other teams had 4 developers, while mine was one developer, one QA, and a tech writer. The tech writer (that’s me) and the QA guy knew some basic Java, and the developer was a hardcore Python fanatic. Guess who had to learn Python in 24h? :-D
Luckily, Python is easy to learn if you know programming basics (like Perl and Java), and there are many code samples to be found. There were some coding tasks that even I could solve and implement (looping over a directory to read icon file names into a dictionary, or setting the window title of the app — small tasks like that). I spent most time taking non-coding tasks off the other guys’ hands, such as finding and integrating icon sets (creative commons), writing a tiny online help set, and writing a stylish PowerPoint presentation.
We had been discussing our options before the game started, and each of us already had made certain that we had the following installed:
- the same version of Python
- the same version of pyQt (a library for the user interface, in case we would need one)
- the same version of git (for file version control)
Apart from that, each team member was free to use their favorite utilities. I chose NetBeans IDE and Cygwin. (The NetBeans plugins for git and Python do not support all features of the command line.)
None of us had prior experience with pyQt, but it was easy to learn and provided good documentation. It took over an hour to download and install everything and find our way around, so it was good we made this decision early and installed it before the contest started.
Similarly, we practiced using git before the contest started. I had prior experience with Subversion, which is quite intuitive: You “svn update” to receive changes from others, then you “svn merge”, and then you “svn commit” to send your changes to the central repo. Git however is decentralized (similar to Mercurial). If you try to use the SVN approach and “git push” your changes to your colleagues, git gets all whiney about write permissions.
An easier approach is that each member has their own local repository where they commit their changes. Place each local repo into a shared (that is, team readable) directory. Instead of pushing your changes to your colleagues, you “git pull” their (publicly readable) changes into your repository. Then you merge and commit again. This requires more discipline than a central repo, since you mustn’t forget to pull from everyone, but we were only three so it worked well to remind each other “hey pull from me”.
With the tools being settled, we still didn’t know what actual task they would assign to us. The organizers had made a big fuss about revealing this year’s (the first ever) theme.
The site manager stood there ceremoniously with 10 envelopes in his hand.
He called one member from each team to step up to the front.
Then he suddenly announced that the first envelope drawn would define the theme for all teams. Ooo-kay…? So the first guy reads out the lot he drew and it said: Write software that is useful and have fun doing it! (And yes, all envelopes had the same content.) Duh. ;-)
Next step was to come up with a spec for our team’s project. It must be something “useful”, a complete application with reasonable features, but at the same time, it cannot be too complex, because the team must be able to implement it in 24h — despite being tired.
I’m really curious what the other teams created — expecially since one of them asked how many GBs they could use to upload their disk image… o_o My team’s desktop app was, like, 10MB… But well, we have colleagues who work on mainframe applications, or distributed cloud software, etc, so they likely wrote something work related. We considered writing a work-related utility (I’m not saying what it is so we can use this idea next year), but our (inofficial) team lead politely asked to have his idea implemented — a Quad Paper Simulator.
Yes. I mean a desktop application that simulates quad paper. X-)
I was the one writing the documentation and the final presentation for it, and I needed some “motivation” or “unique selling point” for this app. “Easy,” said the colleague who suggested this idea: “Clearly, Paint is a simulation of drawing paper, and Word is a simulation of writing paper. What we need, though, is a simulation of quad paper! Excel just doesn’t cut it — it’s lacking an easily customizable icon palette.”
What would one use simulated quad paper for? He gave me some examples: You can plan chess gambits without having to erase stuff or drawing arrows. You can draw a map for D&D, Minecraft, or Nethack (any game with a tile-based map). You can take notes of Minecraft crafting recipes. You can use it to solve logic grid puzzles.
I came up with another example: A friend of mine likes to knit, and she carries with her photocopied quad paper to keep track of her current knitting pattern. She highlights the boxes in a color to track how far she got. Each printout can only be used once – if she had our fabulous Quad Paper Simulator, she could reset the color and reuse the pattern, or she could even adjust the pattern on the fly!
Admittedly, Quad Paper doesn’t bring about world peace, but it was a feasible project that we could tackle in 24h (and it was a sufficiently amusing idea, too, as opposed to writing a fully work related app). Again, I don’t know what great things the other teams produced. (Did I mention that our app opens a really useful CHM help when you press F1?? And our PowerPoint is really convincing and all?? Surely we deserve extra points for that!!) We may not “win” first place, but I’d say we did the best that a 1DEV/1QA/1TW team can achieve in 24h.