A software engineer might tell you that the fastest code is...

[Paul Keith]

A software engineer might tell you that the fastest code is the code that is never called.   Likewise, the most productive programmer is the one that solves the problem with the fewest commands.    Complexity is the arch-enemy of reliability, and its corollary, predictability.     Think about this:  A system with 50 required parts, each one having 95% reliability, has an overall reliability of .9550, or barely 8%!

Cliche idea but I thought some of you may find the statement worth discussing.

Lessons from Grand Central Terminal

from: LewRockwell.com

[Renegade]

And every problem can be solved with 1 more layer of abstraction.

From the article above:

Witness the bewildering sizes of recent pieces of legislation, or attempted legislation, drafted in true “we’ve really got it this  time” fashion.    Obamacare tips the scales at 2000+ pages. The recent financial reform bill is 3000+ (with the original Glass-Steagall act, whose re-birth some people are calling for, weighing in at a paltry 34 pages).   Even the government’s response to the tragically ongoing BP oil spill has been one of triangulation and determined-complexity.

When it comes to legislation, it seems dangerous to have overly complex laws. Nobody can possibly know them all, and yet, "ignorance of the law is no excuse." Bollocks. You can't follow a law if you can't know it, and with legal complexity as it is...

[Eóin]

And there I thought this might be a discussion on software design rather than using it as a bad analogy for politics...  

[Renegade]

Actually, I think the analogy is valid. Complexity introduces additional margin for error, and with the bloat in bills and laws, well, the outcome can only be bad.

[Eóin]

Ok, I was being a bit harsh maybe the analogy works in that sense, but I don't believe it's a 'useful' analogy.

Let's look at it this way, when are large, interconnected computer systems simple? I would suggest, as a hypothesis, that happens when all the parts play by the rules. Then you really can get this wonderful complexity of function from simplicity in the design.

But things get very complicated when you have to account for the edge cases, trying for example to recover from umpteen different errors all of which might require a different tactic. Then how about malicious attacks, inputs specially crafted to crash or subvert the systems? Trying to foresee those is beyond the capabilities of many programmers. Add to that backwards compatibility and well... by now elegance is taking a backseat.

Now what happens in political bills? Well keeping to the analogy we have whats described above. Existing legislation and near endless corner cases must be accounted for. Then any and all loopholes need to be closed because you're going to have thousands if not millions of people actively looking for some way to exploit the systems to their ends. It's no wonder these political bills run to thousands to pages.

But nonetheless maybe I was being a bit glib, I just really was hoping for an interesting programming related discussion.

[mwb1100]

I probably shouldn't be diving into a political-based thread, but here's a few thoughts anyway...

Even if certain mathematical and physical science concepts prove that much can come from simple things, that doesn't mean that all things in society can be simple.  Don't forget - there are even some very complex things in mathematics and physics.

And I'm not even sure what the following has to do with 'keeping things simple':

Even the government’s response to the tragically ongoing BP oil spill has been one of triangulation and determined-complexity.   Get some supertankers to siphon off the leaking oil?   Nope.   Help Louisiana Gov. Jindal to build some temporary barrier islands along parts of the coastline?  No sir.  Keep a boot on the throat of BP — hey, that’s a killer sound bite!  Let’s go with that!

Would these 'simple' solutions even really work? It seems that so far no solutions - simple or complex - have worked yet.  Given that the overall tone of the article is that government is making things too complex, let's take the government out of the picture. What's preventing BP from implementing something to fix the leak?  Forget fixing the leak - what about dealing with the damage?  BP's operation has caused extensive damage, physical and economic.  In the world of simple regulations like, “You are free to fail; proceed at your own risk”, I suppose that BP's failure would be the limit of liability for BP.  But what if that wasn't even close enough to make the people damaged by BP's failure whole?  I guess those people would just be out of luck. Property and livelihood damaged or destroyed by a company running an operation miles away - essentially invisible to many of the people directly affected. I guess BP just isn't following the unwritten rule of common courtesy.  Oh well, too bad for those communities with oil on their shores.

And could a world of super-simple regulation even include corporations (at least as legal entities with rights)?  I'd guess not - that very concept is rather complex.

And, while a software engineer might tell you that the fastest code is the code that is never called, what does that get you? It's also code that doesn't do anything. If that's what you need, then great. But the real trick (at least in software engineering) is coming up with software that does something useful, while making it run correctly, quickly, and keeping it structured so it can be maintained (for fixing or adding new utility).  Some of these goals conflict with each other.  Which is why writing software can be a very complex endeavor.

[parkint]

But the real trick (at least in software engineering) is coming up with software that does something useful, while making it run correctly, quickly, and keeping it structured so it can be maintained (for fixing or adding new utility).  Some of these goals conflict with each other.  Which is why writing software can be a very complex endeavor.

-mwb1100 (June 23, 2010, 12:03 PM)

Very eloquently stated!

The rule of software development.
You can have it:
  Fast
  Cheap
  Right
Choose only two

[Deozaan]

has an overall reliability of .9550, or barely 8%!

-Paul Keith (June 22, 2010, 12:54 AM)

In what world is 0.9550 == 8%?

0.955 is actually better than 95%. It's 95.5%, whereas 8% is 0.08.

Or am I missing something really obvious here?

[mwb1100]

In what world is 0.9550 == 8%?

-Deozaan (June 23, 2010, 01:58 PM)

The formatting might be messed up in some browsers - the number isn't 0.9550, it's 0.95 raised to the 50th power (expressed in some programming languages as "0.95^50" or "0.95**50" or "pow(0.95, 50)").

[Paul Keith]

It's not the browser, I didn't know how to format that quote so that DonationCoder would show the correct quote so I just left the text in with the hope that people will visit the source link anyway.

[Deozaan]

Yep, that's it. The superscript wasn't in the quote! I didn't actually read the article because the quote seemed so wrong.

(Though my calculator says 0.95⁵⁰ is about 7.7%, not 8% but that's just getting nitpicky.)

[rkarman]

Think about this:  A system with 50 required parts, each one having 95% reliability, has an overall reliability of .9550^50, or barely 8%!

-Paul Keith (June 22, 2010, 12:54 AM)

If it think about this I come to the conclusion that it's not true... The internet is built with millions of components (if not more) that all have a 99.98% reliability. According to this theory the overall reliability would be something like:  .9998^1000000=0.000000..(80more zeroes)..1356 etc.

Even if we would consider the internet build of a total of 10000 devices with each a reliability of 99.99999% we still end up with an overall reliability of 1%.

I think that the formula used is somewhat flawed or can clearly not "simply" be used as generic as it is used in this text. So the simplicity of the original article proved that too much simplicity also introduces errors.

The real lesson is ... Simple == Unreliable, Complex == Unreliable. Reliability is not just an accidental by product of complexity, it needs to be designed and implemented. The author of "Lessons from Grand Central Terminal" clearly didn't have reliability in mind when designing & implementing his article.

[mwb1100]

I think the key is the word 'required'.  That implies that if any one of the parts fails, the whole system fails.

The Internet was explicitly designed so that a failure in one (or even more) part(s) wouldn't result in the whole network failing.

But, I think this still makes a point counter to the article:  the article's premise is that complex legislation (or whatever) is almost by definition prone to failure due to its complexity. However, one could make the argument that even a failure in one more components of a piece of complex legislation doesn't necessarily render the entire thing a failure.

[JavaJones]

In fact, most legal documents are written with boilerplate like "If any part of this agreement shall be deemed unenforceable, this shall not affect the enforceability of any other part", etc.

Still, uber-complex legislation is bad, mmmkay?

- Oshyan

[rkarman]

Still, uber-complex legislation is bad, mmmkay?

-JavaJones (July 14, 2010, 07:28 PM)

I agree

The point of the "Lessons from Grand Central Terminal" article was that the complexity introduced in new laws was bad because it only creates more points of failure. Personally I think the bad part of the complexity in legislation is that it hides the fundamental flaws in them (especially from the usually not so bright politicians).

Take the BP example of the article: "Even the government’s response to the tragically ongoing BP oil spill has been one of triangulation and determined-complexity. Get some supertankers to siphon off the leaking oil? Nope. Help Louisiana Gov. Jindal to build some temporary barrier islands along parts of the coastline?  No sir.  Keep a boot on the throat of BP — hey, that’s a killer sound bite!  Let’s go with that!"

The solutions proposed by the article are overly simplistic. They will work and do well for this specific case, but they will not prevent a next oil spill… The harm here is that the solution is still flawed, even though it looks solid.

Corporations are invented with the sole purpose to parasitize off of the common wealth. If you designed the law this way, you should not put out the accidental fire it caused and then think you solved the structural problem. Corporations are by law not liable for the cost they impose to future generations and the public as a side effect of making a quick buck. No oil drilling company has to provide replacement energy reserves for future generations, and no oil company pays for cleaning up future oil spills. This lending upon the future is true for any kind of corporation.

BP was allowed to parasitize society. They are even required to do so by law!

The main problem of the article was again not analyzing the validity of the example used and misusing the example in such a way it has a killer sound bite...



Anyway I was more interested in the software design side of this discussion, since I do believe complexity is a problem when it grows exponentially (which it does almost automatically if you are not very strict in maintaining architecture).

Take building a house as an analogy.
Doghouse (or small software): You take a few timbers and nails; throw them together and voila a doghouse.

Let’s size it up 10 times.

Normal House (medium sized software): You take a few bricks and mortar; throw them together and voila a normal house. It might just work although having it architectured is usually a better solution.

Let’s size it up 10 times.

Cathedral (highly complex software): You take a few bricks and mortar; throw them together and voila a … uhmm ... pyramid?

Without design a cathedral cannot support its size. The amount of materials is too big and the whole thing will collapse under its own weight. The only way to get a lean structure with so much empty space in it is via architecture and design. Complexity is not the problem, complexity without architecture and design is.