The only thing constant in life is change. As a software developer, around 80% of what I do is change software. There are some ways of doing that which make my life easier, and some that make it difficult.

We change software for quite a few reasons. Sometimes, it’s to add a new feature or to fix a bug which alters the behavior of the product. Other times it’s to improve the design of the codebase, while keeping it’s functionality same. Many times, code is changed to optimize the resource consumption, such as memory, space, or time.

When we change software, it impacts three things. The structure of the codebase, the functionality of the product, and the resource usage. We have to make sure how to preserve the rest of the behavior. It doesn’t mean just leaving the code alone. That means ensuring that the existing behavior isn’t changing and that can be tough. The existing behavior is usually very large, unless it’s a greenfield project, and we often don’t know how much of the existing behavior is at risk.

Questions to ask before we change code
  1. What changes do we have to make?
  2. How will we know that we’ve done them correctly?
  3. How will we know that we haven’t broken anything?
There are bad ways to deal with change and then there are good ways. It’s tempting to minimize the number of changes one has to make to the codebase. Instead of creating new methods/classes, simply add the new code to an existing method or a class. Unfortunately, it results in the bloated software. Existing classes and methods grow larger and harder to understand.

There are consequences of avoiding change. For one, you get bad at dealing with changes. Avoiding change doesn’t mean the change will go away. It will just catch up with you later, when you are least expecting it. It generates fear. Many software developers live with a fear of changing software and it gets worse every day.

What’s the alternative? Well, that’s coming in future posts as I read Michael Feathers’ Working Effectively with Legacy Code. This was the summary of the first chapter, Changing Software.