Re: Variable comparisons

[wietse () porcupine org (Wietse Venema)]

Danny Smith:
> Even worse than that:
>
> At one software engineering seminar I attended a *long* time ago, indicated 
> that bugs occur when the complexity of the problem being solved exceeds the 
> ability of the programmer solving it.  They went on to say that if the 
> problem was too complex for the writer, then anyone that comes along to 
> patch the bug will also continue to find it too complex, and hence will 
> likely introduce more bugs into the equation.
>
> The two solutions to this are:
>
> . design simpler systems

I translate that as: try to build complex systems from simpler
ones.  The hard part is to define the building blocks that make
this simplification possible. Unfortunately, this composition and
decomposition game helps only until the real world requirements
change to the point that they can no longer be accomodated.

For example, with non-monolithic mail systems it is natural to use
separate programs for receiving mail and for delivering mail. This
gives you privilege reduction as well as a lot of other goodies.

However, spammers now send mail to every possible username they
can think of. Mail queues clog up with bounced mail unless the mail
receiving program can decide what address is valid; a decision that
non-monolithic mail systems prefer to delegate to individual mail
delivery programs.

> We continue to create increasingly complex systems.  Is it even possible 
> anymore for one person to understand all the implications throughout the 
> whole system?

Only when valid simplifications are available. For example, I can
"understand" the implications of changing something in a network
daemon program, because the TCP/IP and socket abstractions are
available and because they mostly do what they promise.

        Wietse