Darren Steadman

As software engineers do we think about software errors enough?

When I say software errors I’m not talking bugs or crashes, I’m talking about the everyday errors that occur because a user has done something wrong or their system is incorrectly configured. Often you’ll find that when writing software you automatically write the code in such a way to best accomodate things when they are going right and sometimes not as much care and consideration is taken when handling the errors that could occur.

My example of this will be MS SQL Server Management Studio. I’ve been developing software for many years and apart from a few courses at university I’ve pretty much managed to avoid any database work. Well a few months ago a project I was working on required me to start playing about with SQL server and this is really the inspiration for this article.

I can’t entirely remember what it was that I was trying to setup but I remember it being done mostly in SQL Server Management Studio and nearly every time there was an error or an issue I was presented with essentially what is a .NET stack trace. Now some of these stack traces were useful as the exceptions that had caused them had useful descriptive information included in them, but others were completely useless in assisting me with working out what had gone wrong. Usually it involved a few minutes googling the issue and I would be able to find the answer which was usually located in the MS Technet documentation. The thing is if they know what the cause is and they know how to solve it then why not include it in the application?

I realise that in large tools like SQL Server Management Studio that lots of different error states could occur and including all that documentation as part of a standard install would make it massive. At the same time sometimes you are provided with a link to take you to more information, I find that 9 times out of 10 that link takes you to a page that claims there is no more information on the error you are having yet searching the site manually usually presents the answer you are looking for.

With complexity comes errors so I believe the route to at least begin to alleviate the above problems would be to attempt to reduce complexity in products or at least shield it from the user. Secondly trying to better document common issues that could occur so that they can be solved more easily, and thirdly include systems within the application that can detect error states and explain the potential problems to the user before they become real issues.

While software now is 100 times more user-friendly than what it was 10 years ago, it still has a way to go and maybe that would be helped if as software engineers we started to spend a bit more time thinking about what happens when things go wrong in our applications.