Don't be a legacy coder!

I have had some time recently to read up on several topics. Now I am reading "Testable Javascript" by Mark Ethan Trostler. In the introduction of the book he is talking about legacy code and the consequences that has for the code owner and application.
I think the legacy code description in the book was so good that I want to quote parts of the introduction directly. I encourage you to buy and read the whole book. Legacy code is not much debated any more, but that does not mean the issue is solved. Read and act:

"What is legacy code? I’m a fan of Michael Feathers’s definition in his excellent book,

Working Effectively with Legacy Code (Prentice Hall): legacy code is code without tests.

This code either will not survive or will never be touched by anyone. When the time

comes to touch legacy code, it gets rewritten. Take a look at your current project; any

code that does not have tests will likely be rewritten. Probably not by the author of the

code, but by whoever is now tasked with dealing with it—either enhancing or bug-fixing

it. Unless tests are written, this is dead code that will have to be rewritten. The code may

be spectacular, but the only way it will survive is if it never causes bugs and if no one

ever requests enhancements or new features for it. Even then, how happy are you to ship

production code with no tests? Even if the code “worked” before, are you content to

keep rolling the dice? Is your company, which owns the code, content to keep rolling

the dice? Typically the piper must be paid, and this code will just get rewritten. It’s too

bad the company had to pay to have this possibly spectacular code written twice, but

such is the case with legacy code.

As you can see in the matrix shown in Figure P-1, it is very easy for any legacy code

you’ve written to fall into someone else’s hands and be rewritten. That path is typically

less painful than bringing someone else’s legacy code up to speed with tests. It is very

easy to move from side to side in this matrix, as code changes hands constantly, moving

into and out of your purview with great agility. Moving “down” is the hardest path for

code to take; writing tests for existing code is a job no one wants to do, and most people

will go to impressively great lengths to avoid it—typically resulting in a complete rewrite.

Unfortunately, moving up in this matrix happens with some regularity. Code that starts

out with tests can lapse into legacy code if it falls into the wrong hands. Vigilance is

required to keep tests up to date as more enhancements and features are bolted on, but

this is a much simpler process than writing tests for code without any (or with very few)

tests."