First of all, let's look at these two sentences:

What starts as a clean, crystalline design in the minds of the programmers rots, over time, like a piece of bad meat. The nice little system we built last year turns into a horrible morass of tangled functions and variables next year.

And this one:

The patient might never become an Olympic athlete, but we can’t let “best” be the enemy of “better.”

The writer says that if someone gives you a piece of rotten meat and you can't eat it directly, try to recook it because there isn't another way. That is the right attitude toward dealing with the legacy code.

Four reasons to Change Software

• Adding a feature

• Fixing a bug

I think the ability to tell whether we are fixing a bug or adding a new feature is essential, and it seems so does the writer. But then he explains it by using this word: behavioral changes; suddenly, everything becomes so funny because we can not add new behavior without changing the existed behaviors. So both fixing and adding are behavioral changes.

This will give us a point of view that we shouldn't bother to distinguish them; fixing a bug seems a piece of cake, but it is genuinely as important as adding a feature. Let's say: they are the same.

• Improving the design

The writer describes refactoring in this way: It isn't reformatting source code or rewriting chunks; it is a series of small moves supported by tests to know if we are destroying anything during each change immediately, without any functional changes.

• Optimizing resource usage

It is the same as refactoring; the difference is that it will change the memory or time resource instead of the program structure.

Let's put it all together:

In all four cases, we want to change some functionality and some behavior, but we want to preserve much more, so the writer tells us that:

Preserving existing behavior is one of the most significant challenges in software development. Even when we are changing primary features, we often have vast areas of behavior that we have to preserve.

Risky Change

Well, although the writer tries to explain it by a page full of text, I can say it more accessible in one sentence:Embrace the changes, write the damn tests, and do this more often than five times a week