What's legacy code? That's dead programmers stuff, not only there are no comment in it, you can't ask people because they are dead. It written in languages that nobody understand, there is no specification and yet it works beautifully!

"Legacy code" is a term often used derogatorily to characterize code that is written in a language or style that (1) the speaker/writer consider outdated and/or (2) is competing with something sold/promoted by the speaker/writer. "Legacy code" often differs from its suggested alternative by actually working and scaling.

It's hard to tune heavily tuned code.

It is easier to tear down a code than to put a new one in its place.

There's nothing more difficult than a line.

Unfortunately, many programs are so big that there is no one individual who really knows all the pieces, and so the amount of code sharing you get isn't as great. Also, the opportunity to go back and really rewrite something isn't quite as great, because there's always a new set of features that you're adding on to the same program.

Maybe "just one little global variable" isn't too unmanageable, but that style leads to code that is useless except to its original programmer.

If you try to fiddle around with your code to make it efficient, that's the wrong thing to do. Keep on track with the latest hardware. That's the right thing to do.

Approach making changes to a complex system with extreme caution: what you get may be the opposite of what you expect.

Sometimes it's just not practical to go through the effort of creating a new solution when an existing solution will do the job almost as well.

Of course, the test difficulty depends on what you're doing, and on how you're doing it. I'm constantly asking "How much would I have to screw this up to write an incorrect function that passes these simple tests?" Occasionally the answer is "Not much," so I'll throw the code away and start over. It was probably perfect code, but that's not good enough.

Why don't we write code that just works? Or absent a "just works" set of patches, why don't we revert to code that has years of testing? This kind of "I broke things, so now I will jiggle things randomly until they unbreak" is not acceptable. [...] Don't just make random changes. There really are only two acceptable models of development: "think and analyze" or "years and years of testing on thousands of machines". Those two really do work.

The hard parts were: writing code that was fast enough, writing code that was small enough to fit in the cartridge, and writing code that would fit in the RAM. Basically everything was hard.

When we do read code, we find that some of it gets written because of machine limitations, some because of language limitations, some because of programmer limitations, some because of historical accidents, and some because of specifications — both essential and inessential.