Einstein Principle

A scientific theory should be as simple as possible, but no simpler. -- Albert Einstein

Replace scientific theory with:

methodology and you have Minimal Methodologies which is where this thread began.

model and you have Agile Modeling.

software design and you have the Einstein Principle Of Software Design.

I'd always considered the Einstein quote to be a criticism of over-simplified models, in his case, models of nature. Since he added a lot of non-intuitive complexity to our models of nature, one can understand his motivation. -- Ward Cunningham

It might be fun to list a few models that might suffer from this problem ...

Two diodes in series. One can understand how to bias a bipolar transistor with this model, but not how it amplifies.

Pert Charts. Good for understanding interlinked contracts from multiple NASA vendors, poor for capturing the dynamics of small, motivated teams.

Computer Date and Time. Beyond the obvious Year Two Thousand problems, most ignore or incorrectly handle time zones, daylight time, calendar changes or Leap Seconds.

Crc Cards. Good for getting the feel of objects but ignores critical issues like temporal sequence, cardinality and constraints.

I think Einstein Principle is a restatement of Occams Razor. It means that if you have several models (mathematical, scientific, software, etc) that have the same practical implications, you should choose the simplest one. Most of the comments above refer to models that have different implications. -- Yonat Sharon

If you have a "problem" instead of a "scientific theory", it's easier to see that too simple a solution leaves parts of the problem unsolved. And a solution that's not simple enough risks errors (from over-complication) and consumes resources that could have been better used. This is my understanding of (William Of Occam) Occams Razor in this context. -- Steve Merrick

I have heard of a Chinese saying, "Complex problems do not have simple solutions".

See also: On Simplicity

This reminds me of one of Larry Wall's sayings: "Using a simple tool to solve a complex problem does not result in a simple solution." -- John Douglas Porter

This as simple as possible, but no simpler always makes me cringe. It leads to smugness and complacency. For example, Stroustrup uses it of various features, which implies there is no room for improvement in their design. Generally this is not the case; one can look at other languages and see radically different approaches that feel much better.

My problem is not that C++ is too minimalist, or not minimalist enough. I think these thought processes have led it in the wrong direction. What's sometimes needed is a bit of lateral thinking. The maxim impedes that. It encourages you to take a thing and ask whether it can be made simpler, and to be satisfied if the answer is "No", when maybe you should not have chosen that thing as a starting point at all.

-- Dave Harris

Yeah, it can be and has been abused to refer to a local complexity minima rather than a global minima.

There is a bit of a joke and a bit of wisdom in the phrase as simple as possible, but no simpler. Was Einstein really concerned that people might do something impossible, that someone was going to produce something that was simpler than possible? No, he was really saying that one should strive for simplicity, but don't go overboard.

Judging something solely on its simplicity is an overly simplistic approach.

-- Kiel Hodges

["Was Einstein really concerned that people might do something impossible, that someone was going to produce something that was simpler than possible?" If you add constraints like time, human resources, etc. then, yes, some people may be attempting to do things that are impossible. -- Longtime Reader, Sporadic Contributor]

This reminds me that during Einstein's life he was already battling the misuse of the term 'relative' where it was used in obvious non-relativistic situations. I.e., referring to family and moral issues. -- Honor

Simplicity is, in my opinion, not a valid decision criteria. It does not give us a clean rule for separating two alternatives, because it begs the important parts of the question: what task(s) are we accomplishing? And what cost are we counting?

I have been in too many discussions where simplicity was used as a trump card, with the effect of obscuring an underlying value difference.

Perhaps the Einstein Principle is entirely a joke, and this is the point?

-- Roger Hayes

I think it's a joke. Most one line quotations need further explanation from the author. People over-analyze quotes just like they do poems, songs, and Shakespeare. Just because they can. The problem is, they needed to be explained better in the first place.

Especially English Teachers and English Professors, who get paid to do the above.

Well thought-out convenience methods can make a class much easier to use without compromising its design and can reduce the amount of code one must write. The class is more useful and usable.

Nevertheless, I ask myself if a class I am design is minimal in spirit. A class with a big interface is hard to get a handle on and presents more opportunities for increased coupling. So I want to keep the interface simple so that the class is useful and usable. But I don't want to go overboard! -- Kiel Hodges

Kent Beck recommends one Do The Simplest Thing That Could Possibly Work. -- Ron Jeffries

I find this quite a hard judgment call. Users of a class like the convenience, but the implementor of a class would rather have a minimal feature set. Specifically, the re-implementor would. Often a re-implementor needs to know, "What is the minimum I have to write to get everything to work?"

I suspect that current languages don't support this as well as they might. I would like to separate dispatching from access control. I'd like to separate "1st class members", that access and define the low-level representations, from "2nd class members" that are written in terms of the first class ones (but which may warrant re-implementation for efficiency reasons). In other words, instead of objects having an inside and an outside, I sometimes want them to be multi-layered, like an onion.

(I think that Multi Methods and various non-object or post-object approaches show promise. Cf the Cecil Language.)

-- Dave Harris

Are "2nd class members" defined by the class producer or can class consumers get in the act?

When I think of convenience methods, I'm generally thinking of methods that are defined in terms of other (public) methods and that do not access data members. So basically I'm writing "2nd class members", but the compiler doesn't know it. More importantly, subsequent programmers may not know it and might expand the set of "1st class members" without understanding the consequences. It would be nice for the compiler to keep tabs, but for now it's comments, reviews, etc.

It would also be nice for a class consumer to be able to add "2nd class members" to a class within a limited scope.

-- Kiel Hodges

This is the kind of thing that the new Metat Data facilities in Java 1.5 are for. -- Paul Murray

Try Ruby

Personally, I don't like smearing a class interface with "2nd level members". I think the interface should be minimal, simple and contain "1st class members" only. The convenience methods may go into another class which derives from the main class. This approach keeps the simplicity of both the base class and the convenience class. Another factor is the fact that different clients might need different convenience methods. So, instead of having a multi-layered "onion-like" object you get a multi-layered set of classes each one with clean and simple interface.

-- Gigi Sayfan

This inheritance-based approach doesn't work well when the objects are created by someone else. In that case you don't get to choose their class. Even when you create them yourself, inheritance has so many demands on it that I am reluctant to add another.

Adaptors avoid some of the problems. Better, in C++, would be non-member functions. These can be added to some namespace to avoid name clashes. -- Dave Harris

The problem that many people seem to have when they observe that C++, Java, or any language "is becoming too complex" is that they simply don't understand that the problem domains the languages have to deal with are typically getting complex faster than the languages themselves become more complicated (read feature capable) and thus, there is typically a net simplification occurring. As a language matures it becomes capable of doing more and so more gets done with it, meaning that more and bigger systems will be attempted with it and an improvement cycle starts. The answer, of course, is not to throw away the language but to develop it elegantly since the replacement language will simply go through the same vicious bloat cycle. You must be careful not to break the rule of "no simpler" or you are locking yourself out of what you will be able to do and you'll have to start the cycle over without having really gained anything.

There is currently a debate in the Unified Modeling Language community on whether the language is too complicated and the best answer I've heard to date is that if it is not rich enough to describe a system to be designed then it doesn't serve its purpose. And, to be useful, it must be able to describe pretty much any object-oriented system, hence, better to err on the side of richness than being too simple, you can always ignore what you don't need but it's always tough to make up proprietary extensions (although, again the UML has a cool way to make extensions though a concept called Stereotype Classification).

The real problem though, of course, is that the human brain is not getting more powerful, in and of itself, and that is the real problem when dealing with complexity. -- Dion Hinchcliffe

Perhaps I'm trying to say that I don't like to identify "complicated" with "feature capable". Smalltalk is arguably less complicated than C++, but arguably more capable.

-- Dave Harris

I agree very much with that distinction. On All Panaceas Become Poison it was argued that C++ has become too complicated and that Java was catching up with it fast due to library extensions. However, I do not feel complication pain in Java. The main reason that I prefer Java to C++ these days is that it forces less unnecessary complication on me in my domain. That is, it is better adapted to me. It seems that complexity is relative to one's circumstance. People will wade into complexity without complaint if it is readily apparent that there is no simpler alternative. Once there is, or there is the slightest appearance that there is (may or may not be true!), all the old solutions look too complicated. -- Michael Feathers

I have several comments about this discussion. The first is that I believe Einstein is quoted incorrectly. (This is from memory, so I might still be wrong. I'll try to verify and fix this if necessary.) The real quote is "Things should be as simple as possible, but no simpler" and Einstein was talking about scientific education, not theories. To some degree, I think this casts a different light on things. With education, you're dealing with presentation and models, what's relevant at a particular level or in a particular situation, and so forth.

Also, to me, at least, this makes it more clear that we're speaking of a goal rather than a hard criterion. So I've never thought of the quote as encouraging smugness. I've often applied this maxim in evaluating my designs, and I've never once felt that I'd actually succeeded. And when I try to think how I could make things simpler, it always seems likely that the best way is to try some radically different approach that hasn't occurred to me yet.

When I think of Einstein's quote as it applies to software, I often think of the distinction Fred Brooks makes between "essential" and "accidental" complexity (in No Silver Bullet). Essential complexity is inherent to the problem itself, whereas accidental complexity is an artifact of the solution to the problem (usually as a result of poor tools, or a mismatch between the structure of the solution and the actual problem). All software has both kinds of complexity, and the goal should be to minimize the accidental complexity. Again, the idea that this goal is 100% achievable is ludicrous to me. Sometimes I feel I've eliminated as much of the accidental complexity as I know how to, or as much as the tools will allow, or as much as is required at the moment, but I never feel that it has been completely eradicated. If I ever do feel that way, I'll question my own sanity.

"As simple as possible, but no simpler" is a goal that I can approach, but never reach. -- Glenn Vanderburg

I use the quote when I'm warning that it is always easier to change a deeply structured system than it is to understand it. Software, unlike physical theory, can easily be tinkered into ill health or algorithmic death by well-meaning programmers who haven't taken the time to absorb the full set of boundary conditions for which the system was designed. My advice is to change a system only if you see it is wrong or incomplete, i.e., fix it versus break it. Senators and Congressman should have to repeat this principle before every vote. -- Mike Yinger

Simplicity is a result of insight. For example: if you think everything in the sky revolves around the Earth, then your algorithms to describe the motion of planets get very complex, epicycles within epicycles. If you were an ancient Greek you would call it essential complexity. But given the insight that the earth and other planets all revolve around the sun, you can describe planetary motion completely with very simple equations.

The same thing applies to writing software. Whenever you find yourself in a complicated mess, take a step back, and try to figure out how to change your perspective. Often you'll discover there's a more elegant way to make it work. Instead of piling on Epi Cycles, find a new worldview. -- Dennis Peterson

I think Einstein meant to poke us gently and say that pursuit of simplicity past a point that dutifully handles the ugly little details is just a kind of pointless hubris.

He meant that the pursuit of simplicity is essential, but it is also a bit addicting, and one can obsess on the beauty of simplicity, on its look and feel, as opposed to its veracity and utility. And most importantly, Nature doesn't cooperate. Nature does not give a damn whether the solution is elegant.

Nature (the real world) is full of exception cases. Exception cases are ugly and annoying. A handful of simple equations will not always suffice to capture them. They wreck that beautiful symmetry of the code that presumes only the normative case.

Leap seconds and leap years are perfect natural examples. It would be lovely if you could say "30 days have September, April, June and November; and all the rest have 31." It scans nicely. It's lovely and short. It's just not true, that's all.

In the necessary last clause, ("except February, which has 28, and 29 in leap years"), the poetic scansion falls apart. It tumbles from lyric to laundry list. Code to handle some weird little detail looks and feels just like that pasted-on clause that wrecks the little poetic mnemonic. But does it really wreck it?

I don't think so. I think it's funny and humbling, just as there is humor and humility in exception cases. They remind me that the beauty in the Simplest Thing That Could Possibly Work is not always in the way the code looks or feels (strive as we might for it), but in the omission of all other cruft.

Next time you find yourself faced with a February clause (after all of the re-re-factoring and recasting and rethinking), embrace it and laugh. -- Pat Welsh

That's not a correct quote of the calendar poem, so it's not surprising that it doesn't scan properly. I can't recall the exact text either, but I'm pretty sure it's more like this:

-- Gavin Lambert

I'm not sure that that's the best example to illustrate Pat's point - the irregularity of the months isn't natural at all. It's a kludge that people created, presumably in a (futile) attempt to reconcile the period of the Earth's revolution about the sun with the period of the moon's revolution about the earth.

-- Anonymous Catherd

Excuse please, but doesn't that mean that it is, in the most fundamental sense possible, "natural"? That depends - is it natural to insist on a calendar that tries to reflect the phase of the moon (and fails in the process)? Do we care enough for the thing to dominate our calendar?

I disagree that nature is full of exceptions. I believe that nature is full of exceptions to our overly-simplistic explanations. But when we look deeper we find that it really is obeying fundamental laws that we were unaware of. It's the modeling that is complicated because modeling, by it's nature, simplifies, so then you have to deal with the exception cases. -- Brad White

The problem with nature and time is that there are several natural ways of talking about time in ways meaningful to humans: the "year", once around the sun. The "month", the moon once around the Earth. The "day", one revolution. We can also make up arbitrary units like "second", which is carefully defined and never changes (in a given inertial reference frame). The "exceptional" aspect is that none of these concepts quite matches up with the others precisely, requiring calendar hacks. Each unit, considered alone, is quite non-exceptional, though. (Although that doesn't necessarily mean that they are identical; days have different lengths, but it is meaningful and non-ambiguous to talk about "two billion days ago", for a sufficiently well-defined concept of "day", which I could construct but it would be a waste of time.

I think Einstein meant to do the simplest thing that could solve a problem completely. Any simpler solution would be an incomplete solution to that problem. -- Vh Indukumar

Einstein used a lot of his gifted abilities to create a bomb. [Really?] [No, his letter to FDR warning of the potential of nuclear energy started the atomic bomb project, but he never worked on it.] Why didn't he focus his effort into other activity? [Indeed, he was focused on reconciling quantum mechanics with his theory of relativity, and couldn't be bothered with minor things like nuclear weaponry.]

Einstein summed up his approach to solving physical problems pretty well with his quote "Subtle is the Lord, but malicious he is not." -- Chad Thompson

I think the full context of the quote at the top of the page is something like this: Einstein proposed the theory of relativity on the basis of its simplicity. Soon after, some experiments were made that didn't look too promising for the theory so people started criticizing it as being overblown. But Einstein wasn't willing to give up on his theory because it was 'too beautiful to be false' so that's when he added "but no simpler".

I'm pretty sure that I got the details of the story wrong but the idea is that the wily old bastard was very adroitly deflecting criticism from his theory or perhaps criticizing another's theory which competed with him or which he just didn't like. And of course, the comment was so cryptic that people assume it must have been profound. :)

Sometimes, lack of meaning (or substance), leads one to assume there must be hidden depths in a comment (or person's character). Einstein had a great depth of character but that doesn't mean his every comment was profound.

Regarding the experiments that appeared to contradict relativity, Einstein's other rejoinder was that the theory that underpinned the interpretations of the experimental data was even more doubtful in its validity and had less empirical justification than already existed for relativity. It was like proposing a fifth fundamental force on the basis of a few wobbly particles in a mine in Australia.

I was going to take a crack at refactoring this page, but I finally decided to leave it as is. -- Ed Poor

"An aphorism should be as simple as possible, but over-analyzed." -- Robert Daeley

Category Quote

Seems funny to me that such a long conversation could come out of such a simple quote...kind of ironic...maybe we're all missing Einstein's point?

A typical example of the logical fallacy of an appeal to authority (meaning an authority in something other than what is being discussed). Einstein is no expert on "simplicity" or even "scientific theories" even if he has made one or more. Einstein also said "God doesn't play dice with the universe" which turned out to be...wrong. Einstein also believed in God, which we can assume he learned while sitting on his grandmother's lap. How much else of what he has to offer us is of this folksy homespun quality? In other words, unless Einstein is speaking to his own particular field of physics, and even then assuming it hasn't been superseded or contradicted by later discoveries in that area, there is no real reason to listen to Einstein about anything any more than say you High School Gym teacher or the local dog catcher. The cult of Einstein is to lead us to believe that every word that dropped from his lips was pure gold. Alas, it wasn't. -- Mike

--

A scientific theory should be as simple as possible, but no simpler. -- Albert Einstein

Mike, with which part of this statement do you not agree? Are you arguing in favor of complexity for the sake of complexity?

--

Unless one has a personal, intimate relationship with God which can be wholly shared with anyone at any time, no human is an authority on whether God (be it a he, she, or it) plays dice with the universe or not. Einstein's statement to that effect can't be conclusively declared wrong, it's simply one of countless suppositions humans make every day which will likely be left waiting until the end of time for an answer. God is the ultimate garbage collector; it may be out there, it may not, but we won't know for sure until we actually see it in action. Further, even though Einstein's statement isn't pure gold, it at least may discourage some passerby now or in future from having the same thought and rehashing the same in some forum or chat or hologram or other as yet unknown communication medium for everyone else to roll their eyes about.

-- reply to "Unless one has a personal, intimate relationship with God...": You're way over-analyzing this. Einstein's "Dice" statment was purely and simply a statement of disbelief in the correctness of quantum theory. Nothing more. Since quantum theory has since been proven to be true (or at least as close to it as is possible for a scientific theory) that is why people now say that Einstein was wrong when he said "God does not play dice".

"Since quantum theory has since been proven to be true (or at least as close to it as is possible for a scientific theory)"

In other words....not "proven true" at all.

I agree with Einstein.

Keep in mind that Einstein's theories are a kind of complex, relativistic wrapper over Newton's observations. So it's a kind of self-promotion in a way.

Simple Theory: Gravity Attracts

Some observations

This is as simple as a sentence can be: Noun Verb

No.

It illustrates simplicity, but not completeness

It illustrates that when a model is expressed in its simplest form, it leaves out details of relationships and interactions.

It lacks context, preciseness and quantification.

It also illustrates that theories consists, not just of names and statements, but also of a need for progress in forwarding explanations that seem never to reach a state of completeness.

Short sentences like this lend themselves to Visual Thinkers.

A kid with a magnifying glass intuitively understands the meaning: the estimated focal length of the lens being the theory, too close in or too far away both give rise to fuzzy representations that aren't too bright.

See original on c2.com