A simple random walk algorithm:
- Start out systematically
- Hit an obstacle
- Change direction
- Hit another obstacle
- Change direction
- Eventually cover the problem space.
As applied to the problem of cleaning a floor, the algorithm seems to work OK, particularly if you are willing to ignore the parts of the problem space that the device cannot solve (corners, low furniture, complex spaces).
I sometimes see similar algorithms used by IT engineers. They start out systematically, hit an obstacle, head off in a random direction, hit an obstacle, head off in a different direction, and (usually) solve the problem (eventually). Unfortunately many IT engineers troubleshoot this way.
It could be worse – Some engineers start out systematically, hit an obstacle, and instead of changing direction, they just keep on banging into the obstacle. They haven’t figured out that even a random direction change is better than no direction change.
I also see IT engineers ignore the problems that their tool or project cannot solve. Roomba owners presumably understand that the device has limitations and they compensate for those limitations by using conventional cleaning techniques in places where the Roomba has no coverage. With a Roomba, the house isn’t clean until the corners are covered. With IT projects, I sometimes see the project declared a success long before the corners are covered, and I often see requirements that are not easily addressed by a particular tool, technique or workgroup either ignored or arbitrarily declared ‘out of scope’. (I.E. ‘we cannot solve this problem in the allotted time/budget, therefore the problem doesn’t exist.’)
Over the last month or so, Sun Oracle graciously provided us with another opportunity to learn far more about ZFS than we really ought to need to know. While getting sucked into debugging another obscure issue, I tried occasionally to step back and ask if we were systematically troubleshooting or just Roomba’ing around.
Sometimes it’s hard to tell.
