So today I was playing around with a little equation that may in fact explain nearly all of the principles of software design. I don’t know that it’s actually mathematically solvable in terms of numbers, but it does demonstrate the factors present in software development decisions and how they relate to each other. Before I go into the equation, though, I have to define the factors that are present when a designer is deciding whether or not to implement something, or how to implement it:

**Potential Value of Implementation**(V_{i}for short): How “valuable”*could*it be to implement this? For example, if we add something to the program that*could*directly prevent somebody from dying, that’s very valuable. If it simply*might*prevent a future typo in a single error message, that’s hardly valuable at all.The “value” can be for the end user or for other programmers. When we’re talking about design decisions that affect only code, and not the end user,

*flexibility*is one of the major values–how important*could*this flexibility be?The potential value is separate from how

*likely*it is that the situation will occur where you will need it. That’s the next issue.**Probability of Value**(P_{v}for short): What is the chance that this value will be, in fact, realized by an end user (for a feature or functional change) or by another developer (for some design decision)? If we’re adding in code flexibility to allow for potential contact with extraterrestrial apes, that’s not a very*probable*occurrence. If we’re adding in a feature that is immediately useful to every single user, that’s 100% probability. (The number of users that a feature will be useful to is also part of the Probability of Value.)**Effort of Implementation**(E_{i}for short): How hard will it be to implement this? This is a one-time cost–the immediate difficulty of performing the work required to create this thing the very first time. This would probably be measured in person-hours.**Effort of Maintenance**(E_{m}for short): How much effort will it require to maintain this in the future? (This includes any effort added to maintaining the entire program by implementing this.) Will this complicate maintenance for the whole system? This is an amount that increases over time. Similar to Effort of Implementation, this would be most likely measured in person-hours.

What we’re trying to determine is the **Desirability Of Implementation** (D for short). This answers the questions “Is this something we should do or not?” and “What should the priority of implementing this be?”

The simplest form of the equation is:

D = (P

_{v}* V_{i}) / (E_{i}+ E_{m})

Or, in English:

The Desirability of Implementation is directly proportional to the Probability of Value and the Potential Value of Implementation, and inversely proportional to the total effort, consisting of the Effort of Implementation plus the Effort of Maintenance.

However, there is a critical factor missing from the simple form of this equation: *time*. What we actually want to know is **the limit of this equation as time approaches infinity**, and that gives us the true Desirability of Implementation. So let’s look at this from a logical standpoint:

The Effort of Implementation is a one-time cost, and never changes, so is mostly unaffected by time.

The Value of Implementation may increase or decrease over time, depending on the feature. It’s not predictable, and so we can assume for the sake of this equation that it is a static value that does not change with time (though if that’s not the case in your situation, keep this factor in mind as well). One could even consider that the Effort of Maintenance is actually “the effort required to maintain this exact level of Value,” so that the Value would indeed remain totally fixed over time.

The Probability of Value, being a probability, approaches 1 (100%) as time goes to infinity.

The Effort of Maintenance, being based on time, approaches infinity as time goes to infinity.

At first glance, that might sound as though design is hopeless, because maintenance becomes infinite effort–an amount that no Potential Value could surpass–and it seems like *every* possibility must be accounted for, because given infinite time the probability seems to indicate that every possibility will occur. Those are not true statements, though, because you have to think about the *rate* at which both of those items increase. If the fundamental effort of maintenance is very small, then even as time goes on, it will remain small. You could say that there is a “coefficient of maintenance” on any design decision or feature, and that that determines how rapidly maintenance effort will accumulate over time. As far as the Probability of Value goes, if it is a very tiny number, it may remain tiny until thousands or millions of years have passed–so if the Effort of Maintenance increases at a great rate, then it will easily outstrip the Probability of Value and the Desirability of Implementation will approach zero as time approaches infinity.

What this equation *actually* tells us is that the most important factors to balance, in terms of time, are probability of value vs. effort of maintenance. If the probability of value is high and the effort of maintenance is low, the desirability is then dependent only upon the Potential Value of Implementation vs. the Effort of Implementation–a decision that a product manager can easily make. If the probability of value is low and the effort of maintenance is high, the only justification for implementation would be a near-infinite Potential Value of Implementation.

This interestingly indicates why small improvements in programming languages and development frameworks result in such enormous changes in the resulting products–because tiny reductions in the Effort of Maintenance can make tremendous changes in the Desirability of Implementation. Features that otherwise would be thrown away by a product manager as impossible become part of the basic design plan. Polishing the UI becomes more desirable, because it requires less effort for both implementation and maintenance.

And finally, I think that this communicates most exactly and truthfully why simplicity is so important–because *simplicity* is what determines the “coefficient of maintenance” that I talked about above. The effort involved in maintaining simple code increases very slowly over time–sometimes so slowly that you *never* will have to put any maintenance effort into it in your lifetime.

There’s a lot more that could be said about this equation. What are your thoughts on it? Anybody have any ideas of how Value of Implementation could be numerically calculated, or if it might break down into a set of other numerically-calculable factors? Anything you have to say about it, I’m interested.

-Max

You have a percentage and a non-percentage in your equation. If you make both of them non-percentages, maintenance doesn’t seem so daunting. It is the derivative of that function with respect to time that should be looked at to answer such questions. Of course, for that to be true, you have to formally add time to the equation.

I’m not sure I understand your point about the percentage exactly. A probability is by definition a percentage.

If we say E

_{m}= C * t_{1}where C is the coefficient of maintenance and t_{1}is time, then it’s the coefficient of maintenance that we care about, though that may itself be a derivative of something else.-Max

And more as a note to myself, probably the best unit for C is “person-hours per hour”, where 1 would mean “this is being worked on continuously 24-hour hours a day for all eternity.”

where it T? Time.

oh oops… I should have read further.. you mention that. haha….

“However, there is a critical factor missing from the simple form of this equation: time”

The equation also tells us “never maintain software”. Since you can’t control Pv, you should make Em zero and keep investing Ei in different products until you find a large Vi. Then sell your start-up to some fool who deals with Em while you drink Margaritas on the beach. Oh wait, it tells us more: you should pay lots of other people ‘Ei’, then sell the Vi winners to fools. Then you are a VC.

LOL!! I love it. ðŸ™‚

(For anybody who takes this too literally, though–E

_{m}is of course the Effort of Maintenance whether you maintain it or not; it’s just the intrinsic maintenance effort that the change will require.)-Max

There are terms in your equation which are fuzzily defined, and maybe properly so, since the definition will depend on distance and breadth of view. Let me explain. For instance, what is “one product”? In the farthest and broadest view, Netscape pre-4, 6-7 and 8-9, the Mozilla Suite, Firefox, Thunderbird, SeaMonkey, etc., all make up “one product”. As we come nearer and look at it in more detail, Netscape pre-4 is one product, Netscape 6+ is one or two, Firefox is one, Thunderbird is one, the Mozilla Suite together with SeaMonkey is either one, two or three (I’m not sure, and if two, should one place the boundary before or after Sm 1.x ?), etc. From still closer by, each major release (Fx1, Fx1.5, Fx2, Fx3.0, etc.) is “one product” in its own right.

I believe that each of these points of view is legitimate, and that your equation can be validly applied to each of them (with a proper choice of coefficients, of course); but when going from one POV to the next, part or all of the Ei for each “sub-product” except the first becomes subsumed into the Em for the larger whole, or vice-versa when zooming in.

Now the question arises: Should Netscape have done better by not doing anything? By now, a really huge quantity of manpower and other resources has already been invested in the larger “product” I mentioned earlier. Whether that investment has “paid off” will depend on how one measures the Vi, taking into account, yes, dollars, but also freedom of choice, customizability, etc. Also, should the Vi be measured as a “return on investment” for the peope and legal entities who did invest their labour and/or their money into it, or as the total benefit for the world at large?

These are all really good questions.

I’d say that ultimately, one could measure E

_{m}and E_{i}across the whole world–one could make seriously bad API choices that would severely increase E_{m}for users of your library, and that might be something to take into consideration. Usually, though, a “single project” is well-defined, and most of the decisions that I have to make personally are pretty easy to judge just by limiting myself to the factors at hand, that I use my own judgement to determine separately for each individual decision.The method of measuring V

_{i}is really undetermined at this point. I think that it’s somewhat up to the designer and their goals, really. I think that money is a totally valid way of measuring some of these things for some situations (in fact, you could measure V_{i}, E_{m}and E_{i}all in money and come up with a numerically solvable equation, if you wanted, though it would probably not be a broad-enough measurement of V_{i}, and determining the monetary value of V_{i}would be a whole book unto itself), but the total benefit for the world at large is something that I take into account far more often as an open-source developer, I think, than I put value in ROI.-Max

Iâ€™d say that ultimately, one could measure Em and Ei across the whole worldâ€“one could make seriously bad API choices that would severely increase Em for users of your library, and that might be something to take into consideration.Although thinking about that, if you’re a library, V

_{i}is probably “reduction of E_{m}for other projects”, so you might not even have to get too complicated about it.-Max

You call that simple English? I have to admit I have some minor trouble parsing that sentence. I think I understand the equation much better. :-p

Hahahaha, that is a fair-enough statement. I removed the word “simple” from the preceding sentence. ðŸ™‚

It’s assuming that programming is a science. I think should be art. It’s either beautiful or it is not. Considering the hotshot talents that usually get into programming, it would be insulting if you gave them anything beyond guidelines. This equation is not mathematically rigorous, anyway, tjohnjbarton suggests

How do you like this “General Principles of Programming Aesthetics-a reader-interpretative equation”?

Hey Janson. Programming is a science. The

applicationof any science is an art, but just because somebody hasn’t properly developed the science of programming doesn’t mean that such a science couldn’t or shouldn’t exist. It’s just like building a bridge–the data behind it is scientific, but how the engineer chooses to apply the science is an art of elegantly matching constraints and so forth.You know, I think it’s possible that you could actually perform a mathematically-rigorous proof of the equation. I haven’t looked into it, but I think it could be possible.

-Max

Hmmm.

Well, I’ve programmed, mainly for my System Simulation course, and did enough to run it without errors, but it also took a lot of time. All the time, i was drawing flowcharts, and trying to give shape to my ‘liquid’ ideas.

And those who did it in half my time just went Rambo. They kept banging at the keyboard and did it. I was tempted to mouth the proverb about 10000 Donkeys and works of shakespeare, but i realized that i was the one typing for 10000 years.

I’m narrating this anecdote because all those who did it bragged about how they did it by ‘instinct’, artfully etc. You know how collegers brag. But then, college programming is nothing like a major software development activity.

Well, i’m no longer programming regularly, but the glamour of commanding an abject machine slave still charms me. I went through your previous posts and you seem to say exactly opposite of what I used to believe. But hey, you are the real hotshot.

Pingback: Max’ Lesestoff zum Wochenende | PHP hates me - Der PHP Blog

You need to factor in a discount rate: the cost today of $1M in 2100 is much, much less than $1M.

Mmm, true, inflation happens, but we’re talking about effort mostly, and one of the general ideas behind inflation is that an amount of effort put into production is always compensated adequately. So, however much one month of programmer time costs now, it will cost “the same” in 2100, even if that “same” amount is a much larger number of dollars. So ultimately, that factor is irrelevant in the consideration of the desirability of feature development.

-Max

the Effort of Maintenance..you should always maintain it (in my opinion)

IMHO, inflation only happens when the original source of the supply chain is affected. Secondly, like Max says, the “value” of some xyz amount will alyways be directly proportional to the “value” it has after a few decades or even centuries. Thats because the efforts are same!

Peace,

Jenny

I think I am in the middle of the project where I could test the validity of your equation. Got to check what my boss would say. ðŸ™‚

Cool! I have an updated version of the equation, by the way, which I should give you. Basically:

D = (Vn + Vf) / (Ei + Em)

Vn = Value Now

Vf = Future Value

Ei = Effort of Implementation

Em = Effort of Maintenance

Which reduces over time to:

D = Vf / Em

-Max

Lot of smarts in that pogisnt!

Deadly accurate answer. You’ve hit the bullyese!

You really make it seem so easy along with your presentation but I to find this topic to be actually something which I think I’d never understand. It sort of feels too complex and extremely broad for me. I’m having a look ahead on your next post, IÃ‹â€¡ll attempt to get the hang of it!

On the “allow for inflation” topic, remember that there is a difference between Value and Price.

The Value can be constant whilst the Price changes.

Pingback: Understanding the value of software | Software Dev 2k

Quite a fascinating reading.

A few days ago I wrote a more generic article on the value of software (can be found here if anyone cares http://softwaredev2k.com/2011/10/understanding-the-value-of-software/) which I updated today to link to this post for the more mathematically inclined.

Great work indeed!

Pingback: The Laws of Software Design « The Laughing Programmer

Pingback: Code Simplicity Book Review | Tipping Point Media Studios