A colleague of mine recently brought up the idea of “What if it don’t?”
As in, what if it doesn’t do what is expected? Particularly, he was
speaking of programming and running method calls. In his words “most
programs handle the ‘what if it does’ exactly what it says the routine
will do. However, the well written ones handle the ‘what if it don’t’
do exactly what it says it will do.” His thought was that the well
written applications handle exceptions cleanly and elegantly rather
than spitting some random error message out to the end user who has no
power to control why the error message occurred in the first place.
A recent article on ZDNet entitled Google�s three rules
emphasized a software and overall data center design philosophy of
expecting things to break and writing error handling routines into
their environment. It shocked me to read the responses and to see the
prevailing mindset of many applications developers in this day and age.
It shocked me even more to see that mindset prevalent in the enterprise
software space, though I suppose it shouldn’t have given the number of
stories people hear of enterprise software being rigid, inflexible and
generally very difficult to work with.
What rings true in the design is that more effort was placed on
handling the error conditions that are going to exist no matter what
hardware you throw at a problem, rather than throwing complicated
hardware designs and configurations at a problem that needs to be
solved by software anyway. Hardware will fail. Even software will fail.
It doesn’t matter how much effort you throw at it to try to get it to
not fail, it will always find a way. The elegance of an engineer’s
design is in how it handles failures and recovers from them.
