Home | The Wasserman Principle, Part I

The Wasserman Principle, Part I

Posted on Thursday, September 25th, 2008 | Filed under build management, development, entropy, project management

There is this crazy theory I’ve been working on, on and off for probably over a year now. I’m calling it The Wasserman Principle. I got sidetracked for a while, but I’ve been wanting to finish this. In its present form it’s a rambling, unfinished document that needs some work. I’m going to start editing and revising from the top and release hopefully coherent bits and pieces as I go. So here it is, part 1 of TBD.

With every intended change to software, there is a probability that unintended, unforeseen or unrelated issues will be introduced, triggered or uncovered. These issues need to be addressed as part of the primary work at hand, or deferred. The probability of such issues arising is driven by a number of factors, including, but not necessarily limited to:

  1. Software that undergoes continuous change, such as having new functionality added to its original design, will eventually become more complex and can become disorganized as it grows, losing its original design structure. This is the textbook definition of Software Entropy.
  2. The tendency for a software development organization to be good at some things, and not as good at others. For example: a company may be good at building large applications, but not as good at supporting them (bug fixes, relatively minor enhancements; I’ve worked with and for a few consulting companies over the years that fit this bill), while another company may excel at smaller projects, but struggle with very large ones.

For the purpose of this theory, entropy (E) is defined as “the probability that intended changes (C) cause something else to break (I).” By keeping track of the actual values for I and C, you can deduce E for your project or organization:

E = I / C

With a historical value for E in hand, and for a given number of future changes, issues can be crudely forecasted:

I = C * E

So far the math is very simple but abstract, and as a result not very usable in any kind of real-life scenario. I’ll be adding more and more layers of complexity and detail as we get deeper into the subject matter, but this is enough for now.

Comments

Leave a Reply