The Weight of Old Code
Stare decisis is a legal doctrine which assigns weight to the precedents established by previous cases. Consistency is placed at high value, sometimes over absolute "correctness." Consistency provides predictability, which helps individual in societies plan for the future, feel secure, etc.
Software developers like consistency as well, in terms of design and code style, especially within large organizations where many hands may look at and touch the same code. Just like past court decisions, previously written code begins to acquire more and more weight, appearing to be invulnerable to change.
This can be frustrating as software developers frequently want change. Most developers I know are very concerned about "correctness" or best practices. Best practices evolve over time (sometimes quickly) and developers get anxious to update existing code bases to fit into the latest and greatest paradigm.
The thought of significantly rewriting or retesting components to make this kind of change can be daunting. In effect, the old code has taken on the weight of stare decisis.
However, unlike the courts, software developers have many tools at their disposal to minimize the effect on the system in case they decide to make a change. In particular, tools that verify predictability, also known as tests.
Tests can be manual or automated, unit or system level, but all serve the same purpose when updating old code: to convince yourself that the code still works after you change it. You may end up convincing yourself incorrectly, but testing the tests is a level of meta deeper than I want to go right now.
Of course tests have some weight of their own as they require effort either up front to code them or at the end to the execute them manually. However, by taking on this weight, you lessen the burden of the old code and create a space for change.
And that's one of the great things about working with software. You have lots of different ways to do things, so you have lots of choice. Even better, you can minimize the cost of choosing poorly; a failed unit test is fine. So you have a tight feedback loop. With this type of constant experimentation, the thing that surprises me is not the speed at which our field evolves, but that it doesn't change faster.