You may be familiar with some of the following common signs of legacy applications:

• A patch on top of a patch, just like a living Frankenstein application
• Known bugs
• Changes are expensive
• Fragile
• Difficult to understand
• Old, outdated, static or, often, non-existent documentation
• Shotgun surgery
• Broken windows

Regarding the team that maintains it, these are some of the effects it produces on the members of the team:

• Resignation: The people in charge of the software see a huge task in front
  of them
• No one cares anymore: If you already have broken windows in your system, it is easier to introduce new ones

As legacy code is usually more difficult than other kinds of software, you would want your best people to work on it. However, we are often in a hurry imposed by deadlines, with the idea of programming the required functionalities as fast as possible and ignoring the quality of the solution.

Therefore, to avoid wasting our talented developers in such a bad way, we expect a non-legacy application to fulfill just the opposite. It should be:

• Easy to change
• Generalizable, configurable, and expansible
• Easy to deploy
• Robust
• No known defects or limitations
• Easy to teach to others/learn from others
• Extensive suite of tests
• Self-validating
• Able to use keyhole surgery

As we have outlined some of the properties of legacy and non-legacy code, it should be easy to replace some qualities with others. Right? Stop shotgun surgery and use keyhole surgery, a few more details and you are done. Isn't that right?

It is not as easy as it sounds. Luckily, there are some tricks and rules that, when applied, improve our code and the application comes closer to a non-legacy one.