The Artima Developer Community
Sponsored Link

Weblogs Forum
Laws of Software Compexity

10 replies on 1 page. Most recent reply: Nov 23, 2003 10:44 PM by Mike McClure

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 10 replies on 1 page
Carlos Perez

Posts: 153
Nickname: ceperez
Registered: Jan, 2003

Laws of Software Compexity (View in Weblogs)
Posted: Jul 25, 2003 8:52 AM
Reply to this message Reply
Summary
3 Laws of Software Complexity analagous to 3 Laws of Thermodynamics.
Advertisement

Matt Quail has blogged about a first law of software complexity. It's an analogy of the First Law of Thermodynamics, also known as the Law of Energy Conservation. The analogy Matt is that without radical changes in abstractions, a complex system will remain complex. That is complexity is conserved.

I replied in his blog about The Second Law of Thermodynamics, in that closed systems tend to maximum entropy. Entropy means maximum disorder and if you can make the inference that disorder implies complexity. Then a evolving software system without significant external contributions tends towards entropy. In otherwords, to avoid entropy you've got to be constantly adding energy, and in information terms this means organized knowledge. So you have to keep on refactoring, reducing disorganization into organization.

Keep in mind for both laws, when we talk about a closed system, we don't mean static and unchanging. There's a Zeroth Law of Thermodynamics, namely thermal equilibrium. Well I've got a Zeroth Law too for complexity. Software systems tend towards equilibrium with their environment. In otherwords, in a real world environment where change is unavoidable then a system is under constant pressure to require change.

So in summary, the Laws of Sofware Complexity are:

Laws of Software Complexity
  • Zeroth Law. Change Equilibrium - Change is Unavoidable
  • First Law. Complexity will be Conserved - Incrementally changes do not change inherent complexity
  • Second Law. Software Complexity tends to Maximum Entropy - Aggressive refactoring tends to slow down that tendency.

Pretty, "cool" don't you think?


Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Laws of Software Compexity Posted: Jul 25, 2003 10:56 AM
Reply to this message Reply
Deja vu all-over-again.

Metrics and Laws of Software Evolution - The Nineties View
http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf

(Lehman and Belady have been recording laws of software evolution since 1974. It's taught on some CS courses)

A unified theory of software evolution
http://www.salon.com/tech/feature/2002/04/08/lehman/print.html

James Britt

Posts: 1319
Nickname: jamesbritt
Registered: Apr, 2003

Re: Laws of Software Compexity Posted: Jul 25, 2003 11:54 AM
Reply to this message Reply
So in summary, the Laws of Sofware Complexity are:
<snip/>
Pretty, cool don't you think?

Um, well, comparing software to some physical science, such as physics, is not new. The notion of conservation of software complexity is well known.

Still, it's nice to see people discuss this, but I think Matt misses the larger issue. Knowing that complexity is conserved, the question is Where to put it? Who pays for it? In Windows (theoretically), the complexity for end-users is reduced at the expense of those writing the OS (more or less). In most Linux distros, more complexity is pushed back at the user, leaving a more open and (perhaps) simpler system.

I've seen many systems that are hard to configure because the developer wanted it to be easier to write the code. Or systems that don't play well with others because the complexity was pushed out towards the API.

It's like a water bed; if you push down in one place, it pops up in another. App design requires a deliberate decision about who must live with what degree of complexity, and how systems are partitioned to keep complexity from spilling over to other areas. OOP, message-oriented programming, and service-oriented architecture are some of the ways people try to address this.

Most important, though, is seeing that these sorts of analogies are themselves good examples of leaky abstractions. Over-indulgence leads to the same sorts of probems we see, for example, from people who think of the Internet as a highway, or as a printing press, or as TV.

Overplayed comparisons can obscure seeing things for what they really are.

Carlos Perez

Posts: 153
Nickname: ceperez
Registered: Jan, 2003

Re: Laws of Software Compexity Posted: Jul 25, 2003 12:48 PM
Reply to this message Reply
Isaac,

Thanks for the references.

James,

Um, you got to lighten up a little bit! Abstraction not only helps people think, but help people to communicate concepts. Sure, there's some leaky abstractions here and there, but sometimes you can't spend all your time looking at trees, there's a forest out there too.

Carlos

James Britt

Posts: 1319
Nickname: jamesbritt
Registered: Apr, 2003

Re: Laws of Software Compexity Posted: Jul 26, 2003 12:33 AM
Reply to this message Reply
Carlos,

Um, you got to lighten up a little bit, too.

I know about forests and trees, thanks, and I appreciate a good analogy. But they're tools. What's critical is the insight they provoke, and I just didn't find that much in the web log you referenced or the subsequent discussion. No big deal. Maybe there's more to it and it just wasn't expressed very well.

I must confess, though, that a sure way to turn me off from something is to describe it as "cool," which is perhaps the linguistic equivalent of MSG.

(We may need some Laws of Blogging, perhaps something that forbids the use of "cool", "sucks", and any reference to Dave Winer, at least until What Isn't Called Echo Anymore is stable. )

(Do I need to add a dopey smiley face idiogram now?) )

PS: In my previous post I wrote 4+ moderate paragraghs, and your response is to tell me to lighten up, and then explain what abstractions are and why they're a Good Thing?
Disappointing. I'm not trying to be snarky here, but if you disagree with something I said then there have to be better ways to tell me where you think I'm wrong.

Or maybe I'm mistaken about the purpose of the comments section.

John O'Hanley

Posts: 20
Nickname: johnnyo
Registered: Oct, 2002

Re: Laws of Software Compexity Posted: Jul 26, 2003 12:53 AM
Reply to this message Reply
Interesting.

I find the rule about entropy very compelling.

Out of curiosity, is there a standard way of measuring complexity, I wonder?

Seems to me that complexity is inversely proportional to the amount of hiding done by a system. This fits in with the fact the central ideas of OO seem to revolve around one idea: minimize ripple effects by keeping details secret. The more things are hidden, the more intelligible a system becomes. Bizarre, is it not? It's a paradox.

One could define metrics which measure how much hiding is going on in a program.
- SCOPE: number of private methods (hidden to user of the class) versus the number of non-private methods
- SCOPE: number of package-private classes (hiddden to user of the package) versus the number of public classes
- POLYMORPHISM: number of generic interface references versus number of concrete class references
- INDIRECTION: number of repeated uses of the same literal ("magic numbers" versus symbolic constants)

What do you think?

Carlos Perez

Posts: 153
Nickname: ceperez
Registered: Jan, 2003

Re: Laws of Software Compexity Posted: Jul 26, 2003 7:40 AM
Reply to this message Reply
The "cool" remark was supposed to be a pun on "thermodynamics". Oh well! I guess you just never know how people react to jokes. Or maybe I just got lousy timing... oh well!

Celia Redmore

Posts: 21
Nickname: redmore
Registered: Jun, 2003

Re: Laws of Software Compexity Posted: Jul 26, 2003 7:33 PM
Reply to this message Reply
Tesler's Law of Conservation of Complexity: You cannot reduce the complexity of a given task beyond a certain point. Once you've reached that point, you can only shift the burden around. (Larry Tesler)

I'm currently faced with havng to reduce the entropy in some very badly written software. My theory is that entropy is being conserved by increasing the amount in my brain.

http://www.sysprog.net/quotlaws.html

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Laws of Software Compexity Posted: Jul 28, 2003 7:44 AM
Reply to this message Reply
> Out of curiosity, is there a standard way of measuring
> complexity, I wonder?

There is a vast swathe of matherial out there on this subject. One of the most common used to be Function Point Analysis. We used it for a while at my company but, to be honest, found the subject so subjective (so to speak) that it created lots of hot air but little useful information.

The best analogy for complexity measurement I heard was that it was like estimating the cost of building a house by counting the number of electrical power points in the building plan. (So an average 1 bedroom flat might have 9 sockets and an average 3 bedroom house might have 18 sockets.)

What does this tell you? Although it's possible to translate the complexity of a system into a (more or less) simple measure of some or other of its properties, you end up with a result that is vague and/or specialised to the point of meaninglessness. So you need to make your complexity measurement more complex...

Vince.

Celia Redmore

Posts: 21
Nickname: redmore
Registered: Jun, 2003

Re: Laws of Software Compexity Posted: Aug 24, 2003 11:54 AM
Reply to this message Reply
> The best analogy for complexity measurement I heard was
> that it was like estimating the cost of building a house
> by counting the number of electrical power points in the
> building plan.

I like that analogy. It explains why I've always thought of FDD as a CYA-methodology: it restates the obvious in polysyllables.

Maimonides said it best: In the beginning we must simplify the subject, thus unavoidably falsifying it, and later we must sophisticate away the falsely simple beginning.

Mike McClure

Posts: 2
Nickname: mcclure
Registered: Nov, 2003

Re: Laws of Software Compexity Posted: Nov 23, 2003 10:44 PM
Reply to this message Reply
that's the problem with a text based communication medium.
the nuances that we are used to when communicating informally (ie usually vocal) are just not there.

maybe we need to be a bit more rigorous and use tags like <pun>cool</pun>?

Flat View: This topic has 10 replies on 1 page
Topic: Pair Programming – Why You May Not “Get It" Previous Topic   Next Topic Topic: How Many Hello Worlds are Left


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us