Testing updates to old software is much more difficult than testing updates to new software. The older it gets, the more cobwebs form in lonely corners, which drop out of test rotation and concern.

One of my software projects is on its 5th year of steady updates (iteration 80). In software years, this product is 80-years-old. It makes me think of my house, which happens to turn 80-years-old this year.

Seemingly easy upgrades to my old house often result in way more changes than initially planned. When my wife talked me into replacing the cracked pink bathroom tiles, I soon uncovered 6” deep concrete poured between joists that had all but rotted through (due to 79 years of direct contact with concrete.


In the 1920's, I’m sure floating concrete floors were an excellent choice for tiled floors. And fortunately, the old growth pine joists were strong enough to hold the weight…but not for 80 years.

One thing leads to another and before we knew it, we were rebuilding our entire bathroom, including the floor.


Then the changes start to expand way out of scope. The walls will not be compatible with the new floor, so those will have to be replaced (but maybe we'll just patch and replace the worst parts of the outside wall).

Then you realize older technologies are not compatible with newer. You mean Home Depot doesn’t sell Quest plumbing fittings anymore? You mean I have to replace my polybutylene pipes with copper just to move my toilet?

Meanwhile, back at work, my users were asking for the seemingly easy upgrade to allow filtering in the product’s massive control-center-like grid. Sure, no problem…oh, hold on…we can do it but the current grid won’t support it so we’ll have to rebuild the entire module, a testing nightmare (depending on your perspective).

So be careful with work estimates on seemingly simple changes to older products. And try to remember all the often ignored, dependent systems that are affected.