Bugs and warranty in software development
When working in software development for clients, a common problem is warranty. No matter how carefully you develop your software, there will always be bugs. And even when there is no Service Level Agreement, clients will expect you to fix those, which can become quite a costly undertaking. So how can we deal with this? A plea for clear agreements, shared testing and good communication with clients.
Are software issues always your responsibility?
Even though as a driven developer you may feel as if issues in your software are always your mistake and thus your responsibility, the answer to this question is simply: no. Even though the primary cause of bugs in applications is undoubtedly faulty code, this can not always be blamed on the developer. First and foremost because of the most obvious of reasons: all developers are human and in increasingly complex projects, they are bound to make mistakes. No matter how good they are, no matter how hard they try. But there are also other things except for direct mistakes in code that can be responsible for issues.
All developers are human and in increasingly complex projects, they are bound to make mistakes.
Outside factors, for example can easily cause an app to fail. An OS update in which a new feature of the OS suddenly requires extra security in your application could break links used in your app. Changes in the response format of a webservice your application talks to can stop your app from receiving data properly. Even things like clients failing to prolong their Apple developer subscriptions can remove an app from the store entirely. While the latter will not cause any issues in the app directly, issues involving the developer portals will still require maintenance on your side as most clients have no clue what’s going on in there. (Admittedly some developers don’t have a clue either…)
Feature changes or additions are another popular origin of problems. Even though your new version of an application by itself may have been constructed very carefully, it is very easy to overlook that one thing that doesn’t really play well with the previous version. Especially when an update involves changes to the data models, or even databases, these mistakes are made quickly and can have serious consequences.
But one of the most popular problem sources could very well be content. We’ve all dealt with it: angry clients on the phone, complaining about sudden crashes, that when looked into appear to be caused by their own content filled out wrongly or incompletely. When you develop software for clients, you never really see the client as a user anymore. You sort of work together with them on the project, so you forget that they are not really into the tech stuff. They will leave fields blank that have to be filled out, upload animated gifs while your application only supports png or upload huge videos that obviously are a problem when the application has to download them over a 3g network. And my own personal favourite: clients will always and anywhere copy-paste text coming from Word documents, causing those ridiculous quotation marks that break almost any application (even though they shouldn’t nowadays) to end up in your content.
So, we should test carefully…
Yes, yes you should. But testing is not as easy as it sounds. Application development is usually done with a certain budget, and a certain timeframe, both of which are often very limited. When more features have to be added, or the deadline is pulled forward, the first thing that usually suffers from this is testing. Clients, project managers or even developers often don’t see any reasons why testing should take all that long anyway and even though experienced developers should know better, testing is not the most interesting part of the process and you sometimes just can’t be bothered with it.
Clients, project managers or even developers often don’t see any reasons why testing should take all that long.
Apart from that: developers are shit testers anyway. When developing features, you’re focussed on the task at hand, so you tend to test what you’re building, not the accidental effect it may have on other aspects of the app. On top of that: you know how to use the app, since you’ve built it yourself. Users who don’t may (try to) use things in ways you didn’t even think of, making them much better testers. Some apps could even involve domain specific topics of which you have gained only superficial knowledge during your time on the app. So some algorithm giving a result that seems fine to you, may not seem fine at all to people actually in the field.
Ok, so it’s not our fault. Now what?
Although you can never solve every disagreement about bugs between clients and developers, the most important thing you can do is make clear arrangements about what is your responsibility and what isn’t. You obviously can’t abandon all problems when you release the product, but you could agree on a warranty period and set specific rules on which problems are covered by this warranty. Think of it as a SLA for the first period. On any problems that are straight forward bugs in the code, it is common to agree on a warranty period. The period would depend on the type of application, how much it is used and may be the initial budget, but usually something around 3 months is a good basis. Severe complications caused by outside sources can or can not be included in this warranty. Especially in the first period after release when the code is still fresh in your mind these issues are mostly easy to fix, so it could be a nice gesture to include these. When an app depends on a lot of outside resources however you never know what may happen and it open up a world of hurt.
It is also a good idea to agree upon a certain amount of failure that is tolerable. When you have crash reporting built in (which you really should) there may be a number of crashes that you just can’t seem to solve, if only because they only ‘sometimes’ happen. (Don’t you hate it when that happens?) Although it’s also a pain, the fact that they don’t occur a lot means they probably don’t cause a very high crash percentage. If you stick to a crash free session percentage of say 99%, you will have quite a stable application, but still be covered when you just can’t get your finger on those last tricky bugs.
There may be a number of crashes that you just can’t seem to solve, if only because they only ‘sometimes’ happen.
Do it together
Like with issues, good agreements with your clients apply testing as well. If clients have a very tight budget, you can also include them in testing the product. They’re usually very concerned about the product and more eager to start using it than the developers are, and they’re not already biased unless they have been very involved in the development process. (Which in most cases would be desirable, but hardly ever really happens.) If you do this, make clear to your client that testing becomes a shared responsibility and any issues that only surface after the warranty period will not necessarily be fixed without extra funding.
They’re not as bad as you think they are
Apart from agreeing on some terms before you start work on a project, it would also be a good idea to explain to your client, why these agreements are important, and why it is not possible to simply create an application that always works. It may seem like they’re always blaming you, but if you are open about how some things work, clients often understand. If they know beforehand that some things may go wrong (and probably will) it is a lot less of a shock when this actually happens. And they may ask you what went wrong instead of putting the blame on you right away.
If you are open about how some things work, clients often understand.
Another important thing is to realise that your clients, or any third parties involved, are not developers. (And even when they are, that doesn’t mean they cannot do stupid things…) Therefor it’s best to shield your application against outside mistakes as much as possible. When your application uses third party resources, it will always depend on these functioning properly. But you can at least make sure they cannot make your app crash when something is off. This especially applies to entry of content by others. If some fields of the content should never be left empty, you should make sure the tool in which content is entered simple does not allow them to be. The same goes of course for any unsupported characters, image formats and sql injection. If it breaks your application, it should just not be possible.
It’s always your fault
So many things can become a lot easier if you talk to clients up front about what is tolerable and what’s not and set some ground rules. When you inform the people you work for or with of how these things work, and include them in testing the app, they will share the responsibility making the working relationship somewhat less jagged sometimes. Realise however that you’r dealing with human beings: they don’t always understand, and may have peculiar character traits that can make all of this harder than it sounds.
Most of all: accept that no matter what the cause, you’re always going to be the first one they call. The first visible symptom of any problem is always something not working in the application, so without proper knowledge the first place to go is it’s developer. This probably won’t change anytime soon, so it’s best to accept it and be patient with those who call.
