[ahadden]

This is similar to the discussion around "legacy code", which in many ways is corporate speak for "shit code". In his book "Working Effectively with Legacy Code", Michael Feathers provides an interesting definition of legacy code. He defines legacy code as code that is not under test. The idea is that if code is under test then it is easier to improve/refactor.

Maybe instead of saying that code is "shitty", we should retrain ourselves to say that "this code has no tests." It's more productive and points us to a direction out of the situation and prevents us from getting in the situation to begin with.

I suppose some might argue that shit code is not necessarily legacy code or vice-versa. Perhaps, but in either case the first step in improving it is to get it under test.

[anaphor]

I think "shit code" usually falls into two broad categories (or both). Either the developer has a poor understanding of the problem they're trying to solve and comes up with something that is a massive hack/barely works (see: workaround oriented programming) or it was written in a style that the person reading the code considers "stupid" or "outdated" (this would fall into the legacy code category).

[gaius]

Now the question is, who's smarter, some punk kid, or the guy who wrote some code that is still running, still doing its job, still making money for the firm, 20 or 30 years later?

Because that's what "legacy" code is, if it wasn't doing something vitally important, it could just be deleted. It's not shit, it's the family heirlooms!