Your first law - Complexity will be Conserved (...). Software complexity cannot be destroyed, it can only be moved from one place to another - is at first glance reasonable. At second glance, it is trivial to find examples that go against it, for any reasonable definition of complexity I can think of.
Example: Memory management. At the first level, you have implementations of direct data structure manipulation of the free memory pool every place you need to acquire or release memory. At the second level, you have subroutines "AllocateMem(size)" and "FreeMem(ptr, size)" that you call at each place you want to allocate/free memory. At the third leel, you have malloc(size) and free(ptr) that you call when you want to allocate/free memory (notice how bookkeeping complexity went away). At the fourth level, you add reference counting to this, so you don't have to track the frees outside just knowing when you gain and release a reference. This allows quite a bit simpler implementation of many data structures. More complexity went away. At the fifth level, you add a garbage collector (simple mark and sweep will often do.) You stop having to deal with the reference counting, spread all through your program - instead, you just have a fairly small program piece that scan all your memory and see if you have pointers to memory. Complexity disappears.
Example: Web framework parameter validation. At the first level, you have custom validation in every method that accepts web data. At the second level, you add standard validation methods you use to build that custom validation. At the third level, you wrap most of that in a "validate" call, one that check against your validator objects tied into the model and do standardized error reporting. At the fourth level, you make those validator objects form themselves from the database definitions, with only overrides necessary to specify.
I can repeat examples of this at whatever length is necessary. It is possible to write code filling the same specification in many different ways, with different amounts of complexity. Incremental improvement of abstractions can remove complexity. Yes, often they only move it - but far from always.
Eivind Eklund
re:
Posted byceperezat
2008-02-07 05:07 AM
The reason why I use the words "incremental changes". The garbage collection example that you say are not incremental changes, but systemic changes that require massive refactorings. If you are simply moving around code, that is, say you stick to just reference counting, your garbage collection complexity isn't going to change much if you stick to same approach.
The second example about validation involves reducing code by adding meta data. The original examples begins with a lot of code duplication and the final example is one where that information is derived from structure. That is refactoring and it does reduce complexity. When you consolidate common structure, by defining common base classes or commonly used functions, then you indeed reduce complexity.
Example: Memory management. At the first level, you have implementations of direct data structure manipulation of the free memory pool every place you need to acquire or release memory. At the second level, you have subroutines "AllocateMem(size)" and "FreeMem(ptr, size)" that you call at each place you want to allocate/free memory. At the third leel, you have malloc(size) and free(ptr) that you call when you want to allocate/free memory (notice how bookkeeping complexity went away). At the fourth level, you add reference counting to this, so you don't have to track the frees outside just knowing when you gain and release a reference. This allows quite a bit simpler implementation of many data structures. More complexity went away. At the fifth level, you add a garbage collector (simple mark and sweep will often do.) You stop having to deal with the reference counting, spread all through your program - instead, you just have a fairly small program piece that scan all your memory and see if you have pointers to memory. Complexity disappears.
Example: Web framework parameter validation. At the first level, you have custom validation in every method that accepts web data. At the second level, you add standard validation methods you use to build that custom validation. At the third level, you wrap most of that in a "validate" call, one that check against your validator objects tied into the model and do standardized error reporting. At the fourth level, you make those validator objects form themselves from the database definitions, with only overrides necessary to specify.
I can repeat examples of this at whatever length is necessary. It is possible to write code filling the same specification in many different ways, with different amounts of complexity. Incremental improvement of abstractions can remove complexity. Yes, often they only move it - but far from always.
Eivind Eklund
The second example about validation involves reducing code by adding meta data. The original examples begins with a lot of code duplication and the final example is one where that information is derived from structure. That is refactoring and it does reduce complexity. When you consolidate common structure, by defining common base classes or commonly used functions, then you indeed reduce complexity.