The Second Law of Software Design

Now that we know that the future is important, our second law answers the question, “What’s going to happen in the future?” To any programmer who’s worked for any amount of time, this law will be obviously true once you see it, but it’s still good to derive and prove it.

This law is derived from things that we know about the physical universe. From physics we know:

Nothing stays still.

That is, there is no matter or energy anywhere that isn’t moving. Even the atoms in your desk are vibrating furiously, back and forth. It is actually impossible to make them stand still.

So, from that we can then assume:

Anything that exists in the physical universe will change.

Now, that might not be so obvious in some respects. After all, couldn’t you just have something vibrate back and forth forever in one space? Well, let’s ignore that that vibration is “change”, because it’s not really the kind of change I’m talking about. You have to look at it this way: as soon as a vibrating object strikes another vibrating object, one of the vibrations will change. With enough objects in the universe, change then becomes unavoidable. There are enough objects in this universe (particularly the world we live in every day) that change is thus extremely common and likely. Also, people change things, above and beyond these physical laws.

So, you can guarantee this:

The world around your program is going to change.

It could be that you wrote a program for four-wheeled cars and now everybody drives 18-wheel trucks. It could be that you wrote a program for 10 year olds and then 10-year-old education got so bad that they couldn’t use it anymore. Really, it could be anything–the only thing you can guarantee is that something is going to change.

This leads us to our second law of software design:

Your software is going to change.

It’s not going to change by itself, but unless you just give up and decide you don’t want people to use your software anymore, you as a programmer are going to have to accommodate the demands of a changing environment. And that changing environment includes you and your users, too. One day you could wake up and decide that you don’t like how “feature A” works and re-write that piece of the program. Or you might suddenly get new users who don’t like how “feature B” works and have to change that. Really, the possible causes of change are limitless–the only thing you can guarantee is that something will change.

That leads us nicely into the next statement we can derive here, looking at our second law in the context of our first law:

The longer your program exists, the more probable it is that any piece of it will have to change.

That is, as you go into the infinite future, you start tending toward a 100% possibility of every single piece of your program changing. In the next five minutes, no part of your program will probably change. In the next 10 days, a small piece of it might. In the next 20 years, I’m betting that a majority of it (if not all of it) will change.

This is our primary concern in designing for the future–that we allow for and expect change, not that we design ourselves rigid structures that will “stand forever” but suddenly become useless when the environment around them changes.

When you design for the future, you are designing for change.



    • Yes, I know the law of entropy, and I could have used it, but one of my goals with these articles is to be simple, to use ideas and principles that anybody could understand, without having to teach them specific laws of physics or anything like that.

      Anyhow, I don’t think I incorrectly involved physics. My first statement is equivalent to the statement, “It is impossible for matter to reach absolute zero.”


  1. Given that it takes more time to change a piece of software compared to the time it takes for the environment around it to change… can we draw a corollary that “A software is said to be well designed if it survives environment changes without having to change itself”?

    • Yes, you possibly could! At least, up to a certain point. I mean, there are some things about the future that you just can’t predict or design for. For example, before there was Unicode, it would have been impossible to design your program to deal with Unicode, so there’s still going to be changes like that–unknown and unexpected things that you have to allow for. Instead of trying to predict the future, I usually just try to make my software easy to change, so that when it is the future, it’s easy to accommodate the exact demands placed upon the system.


  2. I look forward to reading these laws, and wonder if algebra will make an appearance among them on a list of software design prerequisites.

  3. I was thinking along the lines of how object-oriented programming, or even procedural programming, involves the use of variables – and if you don’t understand that a variable can have its value change, then you’re not going to get very far in programming.

    It goes beyond that, though, in the concept of having letters (or in modern languages, whole words and pseudo-words) represent values and objects.

    • Ah, okay. Yeah, an understanding of the concept of a symbol is necessary to an understanding of computer science, although it would be somewhat irrelevant in software engineering/design, except that it’s a total requirement to understand any programming language.


  4. Interesting ideas behind these laws, and it is somewhat funny to see Panta Rei, a statement some thousands years old, being used in such a context 🙂 No joke intended, I find it really nice to see that we are using Greek philosophy in software engineering!

    • Thanks! Well, if a philosophy does describe the fundamental nature of the universe, it ought to be useful everywhere, eh? 🙂


Leave a Reply