TITLE: complexity and software development

[ Just for a change of pace, this tip wanders up to the level
  of philosophical musings. -adc ]

(Newsgroups: comp.object,comp.lang.c++, 20 Apr 97)


NGUYEN: "Vinh D. Nguyen" <vnguyen@softwaremasters.com>

> I agree with you and think that Robert Martin is incorrect in his
> assessment of complexity. In my experience, complexity usually results
> from:
> 
> 1. Incorrect model of the problem domain:
> If a problem displays apparent complexity, it does not necessarily have to
> be essentially complex. 


MARTIN: rmartin@oma.com (Robert C. Martin)

Here are a few simple counter example.  

Given the very simple formula F=(G*m1*m2)/(r^2), (Newton's law of gravity)  
And given three simple masses in an otherwise unpopulated universe, calculate 
the positions of each object over time.

Find all the prime factors of:
 523453423453029304230492834165498432165498657651654983216549847641358665498463

Write a full featured word processor.  

Now, do all these things without using any complex tools.  That is, do
not use any tools that contain electronics, they are too complex.  You may
use a slide rule if you wish.  

You may think that this is an unreasonable reqest.  I agree.  But it makes
a point.  It takes complexity to manage complexity.  The fact that we
*can* now determine the position of three mutually orbiting bodies to arbitrary
precision depends upon the fact that we can model those objects with computers.
And computers depend upon an immensely complex infrastructure of hardware
engineering.

NGUYEN: 

> It takes skills and knowledge to see past the
> apparent complexity and discover the true nature of the problem which often
> is quite simple. 

MARTIN: 

Certainly there is some truth in this.  Often one can find a very simple
scheme which implements what apeared at first to be a very complex problem.
But things do not always work out that well.  Consider the problem of
writing a word processor.  The task is daunting!  The complexities mount
and there is no simplifying assumption that can eliminate all that complexity.
Regardless of how brilliant we are, the job will remain hard.

NGUYEN: 

> This is the central premise of the study of fractals and
> chaos theory, where structures of high complexity are reduced to very
> simple algorithms. 

MARTIN: 

Rather, it is the astounding fact that structures of immense complexity - that
completely defy analysis - can be created by applying such simple laws.  This
is very similar to software.  The laws that govern a word processor are so
simple as to be almost common sense.  Yet the problem of actually building one
is exceptionally difficult.

NGUYEN: 

> I have many times developed complex solutions to solve
> complex problems only to revise them later once I understood the nature of
> these problems. Always, the new solutions were simpler, more elegant, and
> more powerful then the original complex ones.

MARTIN: 

Yes, this is a common experience.  But *it is not universal*!  Not every
problem yeilds this way.  Some problems remain complex.  

NGUYEN: 

> 
> 2. Wrong level of abstraction:
> As human, we are constrained by "bounded rationality" and thus inherently
> cannot comprehend complexity. However, by defining appropriate levels of
> abstraction and start thinking in terms of these levels of abstractions, we
> can manage complexity successfully. 

MARTIN: 

Quite so.  However, the appropriate level of abstraction sometimes needs
to be quite complicated.  Calculus is a good example.  The techniques of
calculus make a whole class of complicated problems much easier to deal with.
Yet calculus itself is a complex discipline.  Thus, it takes complexity
to manage complexity.

NGUYEN: 

> In general, greater complexity requires
> higher levels of abstraction. For example, if one were to write a drawing
> application in machine code, constrained to think only in terms of
> registers and instruction pointers, it would be a very complex task. 

MARTIN: 

Quite so, although the language itself would be quite simple.

NGUYEN: 

> If
> instead, one start thinking in term of C code, the task would be easier. 

MARTIN: 

Again, quite so, but now the language has gotten more complex.

NGUYEN: 

> It
> would be easier still in terms of C++ objects. 

MARTIN: 

Granted, but now the language is even more complex still.

NGUYEN: 

> As a matter of fact, I think
> one of the main advantages of OOP is that it allows programmers to think at
> high levels of abstractions and thereby able to manage complexity
> succesfully.

MARTIN: 

Truth.  Yet the discipline of OO is more complex than the procedural
discipline.  Thus, once again, it takes complexity to manage complexity.
Our tools gain in complexity in order to give us the leverage to manage
the complexity of the tasks we undertake.

NGUYEN: 

> To sum it up, if a problem appears to be solvable only with a complex
> solution then usually something is wrong, 

MARTIN: 

*sometimes* something is wrong.  Often, however, the solution is
just plain complicated.