stuff about programming
the downside of de-bugging tools
June 21, 2011Posted by on
Imagine this… One morning office workers arrive to find that their office building is leaning over. The boss calls an engineer about the problem who arrives and uses his de-bugger tool to asses the problem.
It identifies that the foundation of the building has cracked and partially collapsed; with this knowledge the engineer advises the boss to fix the foundation. The boss has a worker patch the foundation with new concrete and re-boot the building. The turn around for the fix is quick and cheap.
But a month later all of the employees come to work to find that the building has collapsed completely. Why?
… because the real problem was missed. The original engineer, relying on his de-bugger tool, did not do a manual inspection of the foundation, or the building system to which it is attached, or anything else. If so he would have inevitably investigated many integrated and tangentially-related systems/components.
If he had he would have discovered:
1 – the foundation’s chemical composition is affected by high aridity,
2 – the bedrock beneath the foundation is connected to a small tectonic fault line 20 miles away.
And as it turns out, when these two factors rarely occur simultaneously, such as the other night when the air was very dry and the ground coincidentally shook a little, the foundation crumbles.
It’s interesting to note that if the engineer had done a lengthy exhaustive manual investigation, he would have learned much about the whole building system, and become a better engineer … and that is the point of this story: the process of manual inspection is an important part of the process of understanding how a system is built.
Students should never be shown de-bugger tools, much less taught to use them in the name of efficiency, because more often than not the efficiency that they attain with de-bugging tools is short-sighted-efficiency. De-bugger tools foster less-than-quality coding habits.
And lastly consider this: bugs are a measurement of the quality of your software’s architecture ( and an insight into the planning that went into it’s development ). Lots of bugs usually indicate a bad architecture; a company should reason with this. In my experience it is better, though depressing, to start over from scratch than to attempt to add lots and lots of band-aids to a badly built application.