The primary question that faces software designers is “How do I make decisions about my software?” When faced with many possible directions you could go in, which option is the best? It’s never a question of which decision would be absolutely right versus which decision would be absolutely wrong. Instead, what we want to know is, “Given many possible decisions, which of those decisions are better than others?” It’s a matter of ranking decisions, and then choosing the best decision out of all the possibilities. For example, a designer might ask himself, “There are 100 different features we could work on today, but we only have the manpower to work on two. Which ones should we work on first?”
The above question, and indeed every question of this nature in software design, is answered by this equation:
where:
- D
Stands for the desirability of a change. How much do we want to do something?
- V
Stands for the value of a change. How valuable is this change? Usually, you would determine this by asking “How much does this help our users?” although there are other methods of determining value as well.
- E
Stands for the effort involved in performing the change. How much work will the change require?
Essentially, this equation says:
The desirability of any change is directly proportional to the value of the change and inversely proportional to the effort involved in making the change.
It doesn’t say whether a change is absolutely right or wrong; instead, it tells you how to rank your options. Changes that will bring a lot of value and require little effort are “better” than those that will bring little value and require a lot of effort.
Even if your question is “Should we stay the same and not change?” this equation tells you the answer. Ask yourself “What is the value of staying the same?” and “What is the effort involved in staying the same?” and compare that to the value of changing and the effort involved in changing.
What do we mean by “value” in the equation? The simplest definition of value would be:
The degree to which this change helps anybody anywhere.
The most important people to help are your users. However, writing in features that will help you support yourself financially is also a form of value—it’s valuable to you. In fact, there are many ways a change can have value; these are just two examples.
Sometimes, determining the actual, precise numerical value of any particular change is difficult. For example, say your software helps people lose weight. How do you measure the exact value of helping somebody lose weight? You can’t, really. But you can know with precision that some features of the software will help people lose weight a lot and some features won’t help people lose weight at all. So, you can still rank changes by their value.
Understanding the value of each possible change comes mostly from experience as a developer and from doing proper research with users to find out what will help them the most.
Value is actually composed of two factors: the probability of value (how likely it is that this change will help a user), and the potential value (how much this change will help a user during those times when it does help that person).
For example:
A feature that could save somebody’s life, even if there is only a one in a million chance of it being needed, is still a highly valuable feature. It has a high potential value (saving a life), even though it has a low probability of value.
As another example, in a spreadsheet program you might add a feature that helps blind people enter numbers into the system. Only a small percentage of people are blind, but without this feature, they couldn’t use your software at all. Again, this feature is valuable because it has a very high potential value, despite affecting only a small group of users (a low probability of value).
If there is a feature that will make 100% of your users smile, that is also a valuable feature. It has a very minor potential value (making people smile), but it affects a very large number of users, so it has a high probability of value.
On the other hand, if you implement a feature that has just a one in a million chance of making somebody smile, that’s not very valuable. That’s a feature with low potential value and a low probability of value.
So, when considering value, you also have to consider:
How many users (what percentage) will this change be valuable to?
What is the probability that this feature will be valuable to a user? Or, stated another way: how often will this feature be valuable?
When it is valuable, how valuable will it be?
Some changes may cause some harm in addition to the help they bring. For example, some users may be annoyed if your software shows them ads, even if those ads help support you as a developer.
Calculating a change’s value includes considering how much harm it may do, and balancing that against the help it brings.
Features that have no users have no immediate value. These could include features that users can’t find, features that are too difficult to use, or features that simply don’t help anybody. They may have value in the future, but they have no value now.
This also means that in most cases, you must actually release your software in order for it to be valuable. A change that takes too long to make can actually end up having zero value, because it doesn’t get released in time to help people effectively. It can be important to take release schedules into account when determining the desirability of changes.
Effort is a little easier to put into numbers than value is. Usually, you can describe effort as “a certain number of hours of work by a certain number of people.” “One hundred person-years” is an example of a commonly heard numerical measurement for effort, representing 100 years of work by 1 person, 1 year of work by 100 people, 2 years of work by 50 people, etc.
However, even though effort can be put into numbers, measuring it in practical situations is very tricky—perhaps impossible. Changes can have many hidden costs that can be hard to predict, such as the time you will spend in the future fixing any bugs the changes introduce. But if you are an experienced software developer, you can still rank changes by how much effort they will probably require, even if you don’t know the exact numbers for each.
When considering the effort involved in a change, it’s important to take into account all the effort that might be involved, not just the time you’re going to spend programming. How much research will it take? How much communication will all of the developers have to do with each other? How much time will you spend thinking about the change?
In short, every single piece of time connected with a change is part of the effort cost.
The equation as we have it so far is very simple, but it is missing an important element—time. Not only do you have to implement a change, but you also have to maintain it over time. All changes require maintenance. This is very obvious with some changes—if you’re writing a program to do people’s taxes, you’re going to have to update it for the new tax laws every year. But even changes that don’t immediately seem to have a long-term maintenance cost will have one, even if it’s just the cost of having to make sure that that code still works when you’re testing it next year.
We must also consider value both now and in the future. When we implement some change to our system, it will help our current users, but it may also help all our future users. It may even affect the total number of future users, thus changing how much our software as a whole helps people.
Some features even change in value over time. For example, having a tax program understand the year 2009 tax laws is valuable in 2009 and 2010, but not so valuable once 2011 comes around. That’s a feature that becomes less valuable over time. Some features also become more valuable over time.
So, looking at this realistically, we see that effort actually involves both the effort of implementation and the effort of maintenance, and value involves both the value now and the value in the future. In equation form, this looks like:
where:
- Ei
Stands for the effort of implementation.
- Em
Stands for the effort of maintenance.
- Vn
Stands for value now.
- Vf
Stands for future value.
With everything plugged in, the full equation looks like this:
Or, in English:
The desirability of a change is directly proportional to the value now plus the future value, and inversely proportional to the effort of implementation plus the effort of maintenance.
This is the primary law of software design. However, there is a bit more to know about it.
“Future value” and “effort of maintenance” both depend on time, which causes interesting things to happen with the equation when we apply it to a real-world situation. To demonstrate these, let’s pretend we can use money to solve the equation for both value and effort. “Value” will be measured by how much money the change will make us. “Effort” will be measured in terms of how much money it will cost us to implement the change. You should not use the equation this way in the real world, but for the sake of our example, it’s going to simplify things.
So, let’s say we have a change we want to make where the equation looks like this:
In other words, this change costs $1,000 to implement (effort of implementation, bottom left) and gets us $10,000 immediately (value now, top left). Then, each day after that, it makes us $1,000 (future value, top right) and it costs $100 to maintain (effort of maintenance, bottom right).
After 10 days, the accumulated future value totals $10,000, and the effort of maintenance totals $1,000. That’s equal to the original “value now” and cost of implementation, after just 10 days.
After 100 days, the future value totals $100,000, and the maintenance effort comes to $10,000.
After 1,000 days, the total future value reaches $1,000,000 and the effort of maintenance totals $100,000. At this point, the original “value now” and cost of implementation look pretty tiny in comparison. As time goes on, they will become even less significant, eventually disappearing from importance entirely. Thus, as time goes on our equation reduces to this:[4]
And in fact, nearly all decisions in software design reduce entirely to measuring the future value of a change versus its effort of maintenance. There are situations in which the present value and the implementation effort are large enough to be significant in a decision, but they are extremely rare. In general, software systems are maintained for so long that the value now and the effort of implementation are guaranteed to become insignificant in almost all cases when compared to the long-term future value and effort of maintenance.
The primary lesson to learn here is that we want to avoid situations where, for a given change, the effort of maintenance will eventually outweigh the future value. For example, imagine that you implement a change where the effort and value look like this across five days:
Day | Effort | Value |
|---|---|---|
1 | $10 | $1,000 |
2 | $100 | $100 |
3 | $1,000 | $10 |
4 | $10,000 | $1 |
5 | $100,000 | $0.10 |
Total | $111,110 | $1111.10 |
Clearly, that is a terrible, terrible change that you never should have made. If things keep going at that rate, you won’t be able to maintain the system at all—it will become infinitely expensive and the value you’re gaining each day will become $0.
Any situation in which the effort of maintenance increases faster than the value is going to get you into trouble, even if it looks okay at first:
Day | Effort | Value |
|---|---|---|
1 | $1000 | $1000 |
2 | $2000 | $2000 |
3 | $4000 | $3000 |
4 | $8000 | $4000 |
Total | $15,000 | $10,000 |
The ideal solution—and the only way to guarantee success—is to design your systems such that the effort of maintenance decreases over time, and eventually becomes zero (or as close to it as possible). As long as you can do that, it doesn’t matter how large or small the future value becomes; you don’t have to worry about it. For example, these tables show desirable situations:
Day | Effort | Value |
|---|---|---|
1 | $1,000 | $0 |
2 | $100 | $10 |
3 | $10 | $100 |
4 | $0 | $1,000 |
5 | $0 | $10,000 |
Total | $1,110 | $11,110 |
Day | Effort | Value |
|---|---|---|
1 | $20 | $10 |
2 | $10 | $10 |
3 | $5 | $10 |
4 | $1 | $10 |
5 | $0 | $10 |
Total | $36 | $50 |
Changes with a higher future value are still more desirable, but as long as every decision has a maintenance cost that approaches zero over time, you can’t get yourself into a dangerous future situation.
Theoretically, as long as the future value is always larger than the maintenance effort, the change is still desirable. So, you could make some change where the maintenance effort and the future value both increased, as long as the future value kept on being large enough to outweigh the effort of maintenance:
Day | Effort | Value |
|---|---|---|
1 | $1 | $0 |
2 | $2 | $2 |
3 | $3 | $4 |
4 | $4 | $6 |
5 | $5 | $8 |
Total | $15 | $20 |
Such a change isn’t bad, but it is more desirable to make a change whose maintenance effort decreases, even if it has a larger effort of implementation. If the effort of maintenance decreases, the change actually becomes more and more desirable over time. That makes it a better choice than other possibilities.
Often, designing a system that will have decreasing maintenance effort requires a significantly larger effort of implementation—quite a bit more design work and planning are required. However, remember that the effort of implementation is nearly always an insignificant factor in making design decisions, and should mostly be ignored.
In short:
It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.
That is one of the most important things there is to know about software design.
But what causes maintenance effort? How do we design systems whose maintenance effort decreases over time? That is the subject of the majority of the rest of this book. But before we get to that, we have to examine the future a little bit more.
It is very easy to write software that helps one person, right now. It is much more difficult to write software that helps millions of people now and continues to do so decades into the future. But where is most of the programming effort going to be, and when will most of those users be using the software? Right now, or in those decades to come?
The answer is that there will be far more programming work to be done—and far more users to help—in the future than in the present. Your software will have to compete and exist in the future, and the effort of maintenance and number of users will grow.
When we ignore the fact that there is a future and make things that “just work” in the present, our software becomes hard to maintain in the future. When software is hard to maintain, it’s hard to make it continue to help people (one of our goals in software design). If you can’t add new features and you can’t fix problems, you eventually end up with “bad software.” It stops helping its users, and it’s full of bugs.
This leads us to the following rule:
The quality level of your design should be proportional to the length of future time in which your system will continue to help people.
If you are writing software that will be used for only the next few hours, you don’t have to put too much effort into its design. But if your software might be used for the next 10 years (and this happens far more often than you might expect, even if you think it’s only going to be used for the next 6 months), then you have to put a lot of work into the design. When in doubt, design your software like it’s going to be used for a long, long time: don’t lock yourself into any one method of doing things, keep it flexible, don’t make any decisions you can’t ever change, and put a lot of attention on design.
So, when we design software, the future should be our primary focus. However, one of the most important things to know about any kind of engineering is this:
There are some things about the future that you do not know.
In fact, when it comes to software design, you just can’t know most things about the future.
The most common and disastrous error that programmers make is predicting something about the future when in fact they cannot know.
For example, imagine that a programmer wrote a piece of software in 1985 that fixed broken floppy disks. It couldn’t fix anything else—every single piece of it was totally dependent upon exactly how floppy disks worked. That software would now be obsolete, because people no longer use floppy disks. That programmer predicted “people will always use floppy disks”—something he could not actually know.
It may be possible to predict the short-term future, but the long-term future is largely unknown. The long term is also more important to us than the short term, because our design decisions will have more consequences in that longer period.
Tip
You are safest if you don’t attempt to predict the future at all, and instead make all your design decisions based on immediately known present-time information.
Now, that may sound like the exact opposite of what we’ve been saying so far in this chapter, but it is not. The future is the most important thing to consider in making design decisions. But there is a difference between designing in a way that allows for future change and attempting to predict the future.
As an analogy, let’s say that you have a simple choice between eating and starving to death. You don’t have to predict the future in order to make that choice—you know that eating is the better decision. Why? Because it will keep you alive right now, and being alive makes for a better future than being dead. The future is important, and we want to consider it in our decisions. We choose to eat now because it makes for a better future. But the future doesn’t have to be predicted—we don’t have to say something specific like “I am eating now because tomorrow I will have to save a baby’s life.” No matter what happens tomorrow, it will be a better tomorrow if you eat now rather than starve to death.
Similarly, in software design we can make certain decisions based on information that we have now, for the purpose of making a better future (decreasing maintenance effort and increasing value), without having to predict the specifics of what’s going to happen in that future.
There are limited exceptions—sometimes you know exactly what is going to happen in the short-term future, and you can make decisions based on that. But if you’re going to do that, you must be very certain about that future, and it must be very near at hand. No matter how intelligent you are, there is simply no possible way to accurately predict long-term futures.
Let’s take an example outside of the realm of programming: CDs, which were designed in 1979 to replace cassette tapes as the primary method of listening to music. Who could have predicted that 20 years later, DVDs would be made in the same size and shape so that manufacturers could make CD/DVD drives for computers? And who could have imagined the problems of spinning a CD 50 times faster than it was supposed to be spun, when it was read in a CD-ROM drive?
This is why, in any type of engineering—including the field of software development—we have “guiding principles.” These are certain rules that, when we follow them, keep things working well no matter what happens in the future. That is what the laws and rules of software design are—our “guiding principles” as designers.
So yes, it’s important to remember that there will be a future. But that doesn’t mean you have to predict that future. Instead, it explains why you should be making decisions according to the laws and rules in this book—because they lead to good future software, no matter what that future brings.
It is not even possible to predict all the ways that a particular law or rule may help you in the future—but it will help, and you’ll be glad you applied it in your work.
You’re welcome to disagree with the laws, rules, and facts you read here. Please do come to your own conclusions about them. But you should be warned that if you don’t follow them, you’re probably going to end up in a mess of trouble somewhere down the line, in a future you can’t predict.
[4] Optional note for mathematicians: If you have studied calculus, you may have realized that we’re starting to analyze the limit of the equation as time approaches infinity. In general, you should be thinking of the Equation of Software Design as though it were an infinite series with a limit, not just a static equation. However, for simplicity’s sake, it is written here as a static equation.