The Bad Code Kata
michaelfeathers.typepad.com
michaelfeathers.typepad.com
I'm doing some light internal Windows system stuff right now, and all the business w.r.t. COM combined with a rampant NIH disease and competing coding guidelines results in a pretty gnarly mess.
Ignoring for a moment the endless wars between those who are for one particular style or library and those against, and the slight differences in the amazing number of different string types (they number in the dozens at least), I think the worst of it comes from COM. Rather than use language or library support, they reinvent everything. Now, granted, in this case it lets them do some pretty nifty things (like instantiating objects on remote machines and invoking methods there as if they were native), but the way you end up doing everything with these opaque macros (that are, if you can find where they're defined, usually written unsafely, by the way) just seems too magical, and the idea of passing around GUIDs for fuck all is just crazy. Too many times have I had a problem that, even in the debugger, was completely incomprehensible and unimaginable in traditional or UNIX C/C++, and after asking around and waiting for responses, amounted to "oh, just take that magic incantation out of your header because it's fucking with your vtable and you don't need it" or "oh just rebuild everything because your old GUIDs aren't valid" or something.
Most of my time is spent wandering around blindfolded in a room while angry hungarians pelt me with college-aged black boxes, to the point that I'd say no more than 4% of my time debugging has been spent actually fixing real problems with my own code that I might have made outside of this environment.
Ahhh, that felt good. End angry rant.
In my experience, a lot of "bad code" mimics what you see on a lot of TDWtf stories: (statically-positioned) string operations for everything. Super-fragile, super-slow, but it does work and sometimes is all one can think of doing without looking at documentation.
In any case, I don't think I could bring myself to deliberately write bad code. Enough of my code ends up that way already (though I of course always try to clean up after myself).
I find that almost all of my "bad code" comes from not fully understanding the subtleties of the problem and trying to hack warts onto the original imperfect solution.
Occasionally it also happens that a problem is so complex that it's extremely difficult to keep everything in mind at once - this mostly happens to me in C, when I have to think of memory management, concurrency/asynchronous I/O, as well as the actual problem I'm trying to solve.