1. Application springs memory leak.
  2. The leak is too small to be alarming.
  3. The leak seems to be spread across many modules.
  4. The engineering team finds it too hard to pin point the leak.
  5. Since the leak is small, this is release noted and not fixed

If you have not guessed already what happens next, lets revisit the concept of a memory leak in a C/C++ environment.

trainee – “should we fix the leak?”

guru – “do u know the line of code where the leak is at?”

trainee – “of-course not” (or else i would have fixed it you dumbo)

guru – “r u saying that u cannot conclusively tell what size the leak will be?”

trainee – “I guess we should fix it then”

As you might have guessed by now, the engineering team which release noted the bug was stung by the same corollary that had stumped the trainee. When run under a different set of conditions, the “leak” leaked more and the release had to be recalled.

I guess thats why the leak is called a leak.