You can't stop degradation

There are a lot of patterns, techniques, and approaches that help to write understandable code and build an architecture possible to change. 

The difficult aspect of development is the fact that whatever you will do, the code and the architecture will degrade. 

The question is, why regardless of tries and efforts we cannot change that? 

What degradation is?

The degradation happens when the quality of the architecture or the code is worse than in the past. 

If we define code/architecture quality as "an indicator of how quickly a developer can add business value to a software system" then, when we degrade the quality, we slow down development.

Let's find out why degradation is unavoidable.

The time is against us

Let's imagine you wrote code to fulfill new requirements. You just merged the last commit. A few minutes later you receive information from the product owner/client/business analyst that the requirements changed. There is a need to add one more condition to the code you wrote.
How long does it take to implement it? You just finished both code and tests, you are in the context, and you know the requirements. It won't take much, let's assume you will need a day for that.

Now imagine a different scenario. The work is done, but the product owner tells you about the change of requirements, not minutes but a month later.

How long does it take to introduce the new condition? Yes, you wrote the code. Yes, we are talking about the same code and the change. Yet, you are working on something different now. You need to remind yourself what the feature was about, where is the code you must change, and what design choices were made. 

Luckily, this was only a month ago. This time you will estimate the work for three days.

Now imagine a different scenario. The work is done, but the product owner tells you about the change of requirements a year after the implementation.

How long does it take now? We are still talking about the same code and the change. You wrote it, but it was so long ago you would not even recognize a line. You remember nothing. That's why in this case, it would take you two weeks.

I'm sure, you see the pattern. In all scenarios, the only variable is the period between merging the code and learning about the new requirement. The implementation and the change are the same. Yet, time makes a difference. 

The knowledge is against us

Did you have the same understanding of the business your application is supporting month, year, or two years ago? I believe you hadn't. You were not aware of many details you are familiar with now. You did not know various aspects of the domain that are obvious now. You were not familiar with all terms and definitions you fluently use today. 

You learned it when implementing new features and talking about the requirements. Sometimes business representatives were learning with you. Such discovery is natural and happens all the time. New demands, new regulations, and new observations open opportunities to learn new things about the market.

And month, year, two years ago, you could not reflect this knowledge in the code, documentation, or any other artifacts. No one knew such knowledge exist. 

And when you learned something new, did you have time to update all the pieces of the code? Most probably, you hadn't.

Of course, this is not only "the problem" of the past. Today you know less than you will a year from now. You can design the code that reflects the knowledge of your team. Yet, you can do it only based on the details you know now. Don't get me wrong. I'm not saying you should dig deeper and learn more about the things you are working on. It could be neverending activity. Even assuming you know what the necessary level of detail is needed, the future will bring some surprises and unexpected directions. 

What advice can I give? Do your best with the knowledge you've got now, and accept the new will come.

Are we all doomed?

Does it mean we are in a lost position? No, it only proves the importance of continuous improvements. You cannot stop degradation, but you can compensate for it on daily bases through refactoring. You can do nothing to eliminate it, but thanks to the patterns and techniques, you can slow down the process.

And remember one thing - if time passes and you still can learn something new about the business your application supports, it means you are working on a project worth investment and development. 

It sounds like success to me.