Complexity Is an Emergent Phenomenon
by Thomas Maufer on 21 January 2009 - 04:19:43 PM
To quote the Wikipedia:
Unintended consequences and side effects are closely related to emergent properties. Luc Steels writes: "A
component has a particular functionality but this is not recognizable
as a subfunction of the global functionality. Instead a component
implements a behaviour whose side effect contributes to the global
functionality [...] Each behaviour has a side effect and the sum of the
side effects gives the desired functionality" (Steels 1990).
In other words, the global or macroscopic functionality of a system
with "emergent functionality" is the sum of all "side effects", of all
emergent properties and functionalities.
I love the description of emergent functionality as being the "sum of all 'side effects' having seen this in action as a contributor at last week's IMS Forum Plugfest 6." Half-seriously, this is a very accurate description of computer networking! What does this mean with respect to Network Operators and their Vendors? One of Mu's customers pointed out this week's SANS "top 25" programming errors list
noting a list of common programming errors -- several of which would
easily cease to exist through Mu usage. There was also a related article in eWeek
offering a statement about programming weaknesses that, IMHO, places
too much blame at the feet of the programmers and software engineers:
"There
appears to be broad agreement on the programming errors," SANS Director
Mason Brown said. "Now it is time to fix them. First, we need to make sure every programmer knows how to write code that is free of the Top 25 errors, and then we need to make
sure every programming team has processes in place to find, fix or
avoid these problems and has the tools needed to verify their code is
as free of these errors as automated tools can verify."
This statement is a great goal, and yet it has problems: It starts out
implying that programmers don't know how to write code that is free of
these errors. Empirically, this will always be true! Many of the most talented engineers still write code that contains bugs. While avoiding my
sensitive side, there seems to be a hidden implication that programmers
don't care about bugs. All vendors I know of rank customer-reported bugs as the #1 priority task for
engineers. Vendors take QA/QE very seriously, trying to test code
coverage thoroughly to reduce the chance that a customer will discover
a bug. Bugs discovered in the field are very expensive! But QA misses things.
Why is it so difficult to achieve good code coverage (especially for error handling routines)? Why can't programmers write bug-free code? The key insight is
that getting programs to behave properly depends on process (tools) as
much as on programmers (talent). And tools do improve over time: Certain
classes of "old-school" errors are now caught by compilers or
source-code analysis tools (e.g., uninitialized pointers, certain types
of unsafe string handling, etc.). But static tools will always be
limited to catching only the most obvious types of problems. Besides: A finished software product contains a LOT of code that wasn't
written by the vendor's engineers. Code gets linked with shared
libraries, either third-party libraries or operating system libraries,
and these libraries may have bugs. Sometimes these libraries are "upgraded" behind the scenes so bugs appear in code the previously worked fine. Also, old code that is poorly documented may be re-used without being properly understood. And tools, even compilers, may have bugs. Finally, the bugs
may not be obvious -- they may only be triggered when certain library
routines are called in some specific circumstances.
Source code
analysis can only find bugs in the high-level code. Binary analysis is
more thorough, but it is still just static analysis: The code isn't
being tested by invalid (or even valid!) inputs. For these "top-25" bugs,
the behavior is what's interesting: How does the code react to a wide
spectrum of stateful traffic containing invalid or unexpected inputs, inspired by real-world malformed packets from badly implemented protocols? Tune in next time for more color on how real-world traffic can help
expose programming errors throughout the product development and
service deployment life cycles.
Comments:
Write a comment
- Required fields are marked with *.
|
