Nothing is permanent.

Expect things to change, for they will.

I’ve lived in many cities, and a couple of times even owned property. Ended up moving each time though. I’ve had several different jobs throughout my career, and each time, for various reasons, it became necessary to find better employment. I’ve even had the world’s best cat, but time caught up with him. Heck, I’ve even seen the iconic New York City skyline destroyed and rebuilt. The point is, nothing lasts forever. Things change.

This is particularly the case with business requirements. Sometimes this is because it is rare for the exact requirements to be fully understood, even by the business people themselves. More often though, the rapidly changing needs of the marketplace and the incoming stream of new information leads to changes in needs. As products make their way to the public, the feedback starts to roll in, and this leads to more changes in requirements.

Don’t fight it. Embrace it.

Write your code so it can more easily respond to change. One of the biggest things you can do here is separate concerns. For example, in an order processing system, if you have one method that computes shipping, taxes, and fees when totaling up an order, then it will have many reasons to change in the future. If shipping, taxes, and fees were handled by separate methods, then each method has only one reason to change. The smaller your methods are, the less there is to change when the requirements change.

Also, keep each piece of logic in only one place. When that logic has to change in the future, you should only have to update it in one place. Otherwise, you risk bugs where logic is updated for some parts but not for others.

Generally, when writing software, keep in mind that almost any requirement can change. Nothing is set in stone. Think about how the next developer will need to modify your code in the future.