Sunday, August 29, 2010

Engineering by Roomba’ing Around

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.


http://electronics.howstuffworks.com/gadgets/home/robotic-vacuum2.htm

Friday, August 27, 2010

So close, but yet so far. Microsoft almost gets it right.

When I read Steps 1 & 2 in the dialog box I thought I had died and gone to heaven.

Flash-Uninstall

Then I read step three.

Amusing – except that if Flash crashed, odds are that there is a reason. I don’t have any way of knowing if it crashed because it’s buggy defective, or if it crashed during an exploit attempt. Of course if it’s the later, I don’t have any way of knowing if the attempt successful or not.