ref: ball of mud

A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design.

Programmers should be extremely vigilant, and continuously roam their own code making sure that it actually reflects the current state of assumptions about the system. Whenever a change is made to the system, anything remotely affected should be proactively rewritten to reflect the change. This is pretty much how Abrash describes himself and Carmack working on Doom and Quake, and it is really successful. You keep performance up, stay in touch with your code, and never accumulate cruft. Bugs are immediately ferreted out and the programmer must never fear diving into code to tackle a big cleanup job, and can never allow pieces of code to exist that she (or he) doesn't understand.

Of course, you need massive automated tests to make sure your rewrites don't screw anything up. Designs must be extremely abstraction oriented, with a close eye to strong interfaces and bootstrapping, otherwise you will end up with so much code that it is impossible to manage the continual cleaning. And you need really dedicated programmers.

When I look at the Doom and Quake source, and the code that my own dev. team has produced, I see that the results are worthwhile. Each routine is beautifully crafted and works flawlessly. The codebase is a fraction of the size you would expect because so much effort has been put into doing everything the right way and eliminating broken or excessive code. And no bugs...