Support questions and bug reports

They're part of every-day life in the software business: users or colleagues encounter problems, and they need some way to find solutions. Sometimes a quick email is the answer, but generally speaking, there should be procedures in place to handle these items efficiently and transparently.

At my day-job, we have an internal application called MIA, which offers a complete environment for running a software business. Aside from the more mundane tasks of accounting, billing and license keys, it also keeps track of complaints, incidents, modifications and releases.
There is a web interface where customers can enter their issues, the support team picks these from the queue and tries to resolve them; if necessary, these incidents are escalated to a software engineer, which can result in a solution or a modification. The customer can track the status of the incident and if development is needed and scheduled, the planned version is added to the display as well.
We have corrective, functional and structural releases of our products and depending on the type of incident, it will be resolved in one of the next releases. Overall, it is an efficient system that our customers appreciate very much - even if they may not always like how long it takes to actually implement the change.

Of course, the situation is a little different for Quartam Software. It is mostly a one-man-show - apart from the external accountant who takes care of the taxes, and some help for the other accounting duties, I take care of everything: sending license keys, answering support emails, developing new features and fixing bugs, plus the information requests as well as the consulting and custom software jobs.
Unfortunately, that means I can't get to everything as quickly as I wish. I do try and get back to people in a reasonable time frame, and try to offer patch versions when some big problem pops up and the next functional release is still some time off. Sometimes, I fail to meet my own standards. But I, Jan Schenkel, am the person to send emails to, for everything.

In a larger organization, that is simply impossible to do: the manager is there to run the business and ensure the commercial success while the operations run smoothly. When procedures are in place, they should be followed to ensure that every item is handled correctly by the designated person. Only when things don't appear to be moving or important issues seem to get ignored, should you go one step higher, and involve management.
But please don't do it for every item that crops up, and be willing to compromise. The customer may be king, but the guy with the compiler is not a serf.

The 15 Minute Fix

Every once in a while, you hear the infamous words "That should only take 15 minutes to fix" - often spoken by someone who isn't a professional software developer. While it is true that a number of bugs can be rectified rather quickly - think: typo or simple inversion of logic - the change in the source code is only a tiny part of the process.

At my day-job, we have to pay extreme attention to the accurate workings of our software. As we cater to the healthcare indsutry, the lives of patients may well depend on our software. The physicians need acuurate data to apply the best treatment, so it is our duty that we correctly handle all the input coming into our laboratory informaton system, as well as the output we produce in the form of reports or data exchange with the general hospital system.

This means we follow a strict procedure for every modification to the source code: analysis -> analysis review -> code -> code review -> unit test -> integration test -> documentation + localisation -> final review. Exhaustive test plans are executed at every release to ensure that the software is reliable and that one change doesn't have a hidden impact on another part of the system. And that's something which simply can't be done in a quarter of an hour.

Even then, you can never be sure that your program will doexectly what it's supposed to do. There are many internal and external variables at play - and even if a computer is supposed to be a deterministic system, where the exact same actions should have the exact same result, errors do occur that are sometimes hard to figure out. Computer software is a composition of many layers - hardware, operating system, frameworks, libraries - most of which are outside of our control.

Yet we all rely on technology and the building blocks we have, to build new functionality, patch existing code and sometimes make radical changes. And we hope that the person who built that underlying layer, is at least as smart as we are, and caught all the mistakes before that layer came to us for further use. Looking at the giant software companies' bug lists may leave you in a bit of a shock when you see thousands upon thousands of entries, some lingering for a decade.

Is it all gloom and despair though? Definitely not - there are plenty of good practices we as developers can and should apply. Where I used to only care about producing the code for the features, I now take the time to write tests for my code, and run my libraries and applications through a battery of manual tests before releasing them into the wild. That sure prevents a lot of frustration for testers and myself, yet even with all that care, sme things are bound to pop up in the field.

A quick internal build for test purposes may only take 15 minutes - but a real solution, fully tested and vetted, that can't be done in such a timeframe.