Have you ever tried to grow your own vegetables from seed? It's a long, slow, but gratifying experience. Building great code is no different. In gardening, it's perhaps more common to skip the first step and buy plants as seedlings from the nursery, and programming is much the same. Most of the time, when we join a project, the code already exists; sometimes it's happy and healthy, but often it's sick and dying.

In this situation, we are adopting a system. It works, but has a few thorns—Ok, maybe more than a few. With some tender loving care, we will turn this system into something healthy and thriving.

So, how do we define a healthy system? The system we have works; it does what the business needs it to do. That's enough, right?

Absolutely not! We might explicitly be paid to deliver a certain amount of features, but we are implicitly paid to provide code that can be maintained and extended. Beyond considering why we are paid, let's take a more selfish view: do you want your work tomorrow to be easier or harder than it is today?

A healthy code base has the following key features:

• High readability
• High testability
• Low coupling

We have talked about or alluded to all of these asks in part 1, but their importance means that we will go over them one more time.