Powered by Blogger.

Perfect Software: Does it exist, should we try to achieve that or second best is fine


Recently I was reviewing code and while going through it I had this question with me whether we should try to target foolproof code handling every possible scenario, every possible value for every condition or should we just plan checks/validations on possible real-world scenarios for that piece of code and rest if at all they happen, let's just figure out when it happens.

The code in question was a call back method from a dispatcher that would check a flag in the database (through WCF call) and if the flag is true then start another timer to shut down the application. Now this timer value will also be fetched from the database at runtime along with the message which needs to be shown to the user. Another condition was that during shutdown timer execution the main dispatcher still keeps on calling this method after the regular interval and if the flag in the database is again changed then it will stop the shutdown timer.

Now, here we had multiple database calls and various conditions which would affect the code flow. Also, what about if the database returns incorrect value for flag or timer or message, what about if the service call fail; what should happen to dispatcher should it continue and come back again to check or just stop. What is the flag is set to true (meaning we do need to shutdown application) but we don’t get the timer value should the application shutdown immediately or should there be the default value for just this case.

To create a perfect method we would need so many possible scenarios to be handled and then there is a fear that more code means more chances of failure even if the code is to avoid failure. We brainstormed about what all validations we should add, should there be the default behavior of the method, should there are default values for each database calls, how to make sure that shutdown can be managed even if there is some exception in code. We specifically had discussions on exception handling, should we have try/catch, where should we have try/catch, what should we caught.

We end up discussing scenarios which we knew in all probability will not happen and I think we're wasting our time

Then we came to a conclusion that we should handle all possible null/invalid format validations but we should have a generic behavior for other failure conditions like if the first call returns flag as true then we should shut down the application irrespective of the timer value (if not fetched), and if the service/database call fails then we should stop the dispatcher there and then and show a message to the user to contact the system administrator.

This review helped me learn that we should try to look for the best possible solutions and not The Best solution for every case, we should build on the best possible solution on specific scenarios because we may end up wasting time looking for being a perfect solution which can work everywhere when we should look for a solution which may be good enough for that specific application/method.

No comments