Code accrues more code over time. This is what makes working with legacy code bases so difficult. The longer it has been around and the more people who have touched it, the more there is to work through to understand how the thing works. This is why most programmers abhor legacy code bases. It goes against everything they teach you: small, fast, minimal. Instead you have big, hairy, and weird (hey… wait a minute). But it is inevitable as stake holders and customers continue to demand new features and “bug” fixes.
I work on one such legacy code base at the moment. I try to keep a good attitude about it, but I sometimes just need to let off some steam. I did so one night while talking with a friend about some of my recent troubles with porting this stuff. I was frustrated with how much action I was observing at a distance within the system. One call into the legacy code base can initiate several other effects in unrelated areas of the system that aren’t documented anywhere and it’s obfuscated by the code. It’s like the programmers who worked on this stuff just added more code when they needed to solve a problem. What he did next made me laugh — he started humming the Katamari Theme.
To brighten my spirits he suggested I should just try humming it and solve all my problems by just adding more code. After all, if you can’t beat them join them, right? He was just kidding around but it got us to thinking of a fun little programming contest: the Katamari Coding contest.
The idea is to add as much code as possible to fix the output of a given function. The code is your Katamari. You still have to call into it at the end of the day, but you got to wrap it with as much code as you can to get the output fixed. Whoever adds the most features on top of it within the time limit of the contest, wins.
It sounds like a terrible idea, but it reminded me of one thing. We programmers have to relax once in a while and stop being so serious all of the time. Purposefully bad code can be fun just for the heck of it.