#FOChaCo: Fear of Changing Code

In code, as in life, things are always changing, whether we want them to or not. (Focusing on the code part,) Operating systems, libraries, protocols, languages, standards, and best practices are changing on the regular underneath every bit of code we write. While many of these systems work hard to change in "backwards-compatible" ways, sometimes there are changes that break things. As software developers, our job is to write our code that is robust to change, so that it still works well when the future arrives.

But sometimes there are those among us who suffer from #FOChaCo: the fear of changing code. Despite the inevitability of the future, they fight tooth and nail to keep things exactly as they were. They might insist that we cannot support anything later than version X of our platform, or that we should not update any libraries unless there is a dire need to do so. These developers are well-intentioned. They may have been bit in the past by a library update. They might have to deal with clients equally reticent to do platform updates. That is no excuse for not accepting that the future is coming.

Sometimes the well-intentioned are more subtle, saying things like, "let's make the smallest change we can to get this new thing working." On the surface, this seems like a correct sentiment. We don't want to do work just for the sake of doing work, and sometimes this is exactly the direction that is needed. Other times, though, it's like telling us to keep digging to get out of the hole. In Sandi Metz's talk "Less - The Path to Better Design", she introduces diagnostics for good code in the form of the acronym TRUE. The "R" stands for Reasonable, which she defines as: "The cost of adding a new feature is proportional to its value." The smallest change we can make is not necessarily the right change to make if it is out of proportion to its value. The smallest changes are often just throwing a few more ifs in there, ignoring reusability or modularity. Those little ifs add up, though, and start to overwhelm everything else. That's when we can find ourselves taking months just to get something out the door. The fear of changing code leads to the inability to change code.

We need to invest in the tools to blunt our fear of change. There are a few that make the biggest difference:

Source Control

With source control, we can always go back to the way things were if we run into trouble. Ideally we will be making small commits often, meaning we lose very little if we have to go back. Source control starts to build in a minimum level of confidence.

Code Reviews

Code reviews make sure that many eyes are looking at changes. The more people looking at a change, the more we can be confident that someone has checked for the obvious (and maybe not-so-obvious) bugs.

Comprehensive Tests

Comprehensive tests give us a very strong sense of confidence. We can know that if we change something and introduce a bug, very likely a test will fail and give us almost real-time feedback. With tests (especially fast tests), we can be more confident that we will not have things breaking unexpectedly.

Code Quality

All of the above are progressively more important, but we cannot really have the most confidence unless we have a focus on code quality. Only with a high level of code quality can we see the boundaries and the connections between the pieces in a well-defined way. With code that is broken down into small, reusable pieces, we can make many more open-closed changes that only add or delete code, but do not change working code. We have the highest level of confidence that as long as we adhere to well-defined interfaces (conceptual interfaces, not necessarily code interfaces), our code can reasonably be expected to work as we intend it to.

Each of the tools above builds on each other. Source control enables code reviews, as a test suite enables building quality code. While you can have some without the others, the full benefits are not realized without all of them.

You may be wondering if that means that the legacy code base on the shared drive that is in production that everyone live-edits is hopeless. It's not, but it will take some effort to make things better. Working down the list, starting with getting things into source control, then introducing code review, and so forth, will drive the code to a better place. Even getting a small piece under test and modular is a win. We will slowly build up that confidence. There will be occasional missteps. Updating that library may cause something to break, or updating the platform may mean that a critical feature was removed. That's no reason to stop or to falter. Things will still keep changing, and it is our job to keep up, and keep our #FOChaCo at bay.