Comments on: Matt’s first law of software complexity

By: David G. Miller

David G. Miller — Fri, 11 Nov 2005 05:01:49 +0000

I’ve always referred to this phenomenon as “the law of conservation of difficulty.” You might also look at RFC 1925 (which really isn’t a joke even if it was posted on 1 April 1996). In particular:

It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.

    (6a) (corollary). It is always possible to add another level of
         indirection.

Cheers,
Dave

By: Rajesh Vasa

Rajesh Vasa — Wed, 18 Feb 2004 05:25:25 +0000

A very interesting observation. I am a researcher in the field of Software Evolution, and I have collected a large amout of data from a very many number of systems (All Java, Open Source). The most interesting find is that my data supports your First Law. Complexity does not change at all once a Software system has stabilised. And the even more interesting thing is that this near constant complexity distribution holds at all levels, i.e Method/Class/Package/System.

By: Frank Nestel

Frank Nestel — Mon, 28 Jul 2003 12:10:38 +0000

Well, interesting thoughs, I just wonder how this well known facet fills in:
"Every piece software will be maintained so long until its complexity is beyond scope for everyone maintaining it."
Concerning real world settings. The question is whether the main purpose of abstractions is to help the gurus to prepare building bricks the mortals can handle. Every now and then the abstraction leaks and you have to call for the guru cause you do not understand what is going on, but in generall you have a nice simple black box labeled "miracle". For a simple example, I’ve found das many young programmers do not know the hashing algorithm. While an efficient assoziative storage is beyond their own design expertise they can use Perl assosciative arrays or Java Hashtables/Maps without harm. Most of the time they have no problem.

As a trained mathematician I know mankind can build abstractions on which the next generation can move very safely. Software of course is all very young. No much time to mature…

By: Pete

Pete — Mon, 28 Jul 2003 00:28:50 +0000

Good post, Matt.

It highlights one of the classis issues in software development - Are we providing a solution to the right problem? Solving the wrong question, as you show, always adds unnecessary complexity.

The other issue that clouds things pretty well is to recognise the complexity in a solution (as opposed to the constant complexity in a problem). Any given solution's complexity can be far in excess of that mandated by the problem. In this case abstractions can assist greatly in reducing complexity. Often in the process of pulling out useful abstractions the developer can come to the realisation that much of what they are doing is superfluous and doesn't actually assist in solving the problem. This kind of activity can remove the extraneous parts and lead to the replacement of core pieces of the system that were mis-designed (if that's a word).

Cheers, Pete.

By: Matt Quail

Matt Quail — Fri, 25 Jul 2003 12:03:54 +0000

Carlos,
I agree that the 2nd law is a whole other bag if fish! I have some thoughts on a "2nd law of software complexity" but I’m not sure how far I can stretch the analogy.

I like the idea that to avoid entropy you have to keep on refactoring

By: Carlos E. Perez

Carlos E. Perez — Fri, 25 Jul 2003 11:58:04 +0000

Sorry, a bit to quick.

Good insight on the first law.

That is if you don't make any radical changes in abstractions, a complex system remains equally complex.

By: Carlos E. Perez

Carlos E. Perez — Fri, 25 Jul 2003 11:54:19 +0000

Wait a minute here. You started out quoting law of energy conservation however not mentioning the equally important 2nd law of thermodynamics.

2nd law of course as applied to information is that a closed system tends towards entropy, that is maximum disorder. If disorder implies complexity, then maximum complexity.

So, to avoid this you've got to be constantly adding energy, and in information terms organized knowledge. So you keep on refactoring, reducing disorganization into organization.

Of course the big law you've got to quote is "the only thing unavoidable in software is change".