6

We have been building custom software for one of our customer for a few years now. Everything is going well so far.

However the customer always has an attitude that when they find a bug in the software, then they are getting really pathetic and complain that they are now really disappointed with the quality of the software: Because if they found this one bug then there surely must be other bugs, so they assume that the quality of the software is getting worse. It's almost like a proof by induction: If there is one then there must be many.

To me, there can always be bugs (the software is part of their CRM solution, so nothing like software used to run airplanes, nuclear reactors, etc.) Obviously, we have various means of testing, but we (or the customers) are not testing everything, so bugs can slip through. Which is OK in my opinion.

But how would you react to such a pathetic and emotional response? I am always totally speechless when they start this way.

Improve this question
16
  • 24
    By choosing to characterize the customer's response as "pathetic," you are already doomed. Customers are never pathetic, just frustrated, and if the bugs are legitimate, you are the problem, not them.
    – Robert Harvey
    Jul 30, 2014 at 20:44
  • 3
    Instead of dismissing the customer, look at the sorts of bugs that are causing them unhappiness and redirect your testing efforts there. They may indeed have unreasonable ideas of quality, but that's hard to say without details. It may be that you are focusing your quality efforts in the wrong areas, spending lots of time testing features they don't care about, and not enough on their business critical features.
    – Gort the Robot
    Jul 30, 2014 at 20:54
  • 4
    @RobertHarvey: I think you absolutely failed to understand the problem here. It has not at all been questioned whether the bugs are legitimate, but rather how the customer emotionally reacts to that. Yes, there are bugs in all software (all the way down to operating systems). Yes, they need to be fixed. But anybody thinks their presence is the end of the world, then they are not just pathetic. They are delusional.
    – back2dos
    Jul 30, 2014 at 23:23
  • 2
    @RobertHarvey: Are you actually suggesting that one needs to be a psychologist to deal with emotional issues? And if so, not being a psychologist, what makes you certain that one needs to be a psychologist to answer the question? I for one am hesitant to believe that psychologists are inherently more able to propose workable solutions to this problem than people who actually have experience in dealing with it. But yes, I understand that anything with a human component has been declared out of scope on this site, so I guess you are "right".
    – back2dos
    Jul 30, 2014 at 23:43
  • 4
    @Izkata That would be fine, if that's what the OP had asked about, but it's not.
    – Robert Harvey
    Jul 31, 2014 at 1:32

8 Answers 8

Reset to default
16

It sounds like for the most part, you have a good relationship with this customer. ("Everything is going well so far.") Presumably you want to keep that relationship.

But it sounds like this scenario has occurred more than once. Perhaps you have somehow (unintentionally, perhaps) let the customer believe that you aren't bothered by these occasional bugs as much as they are. If so, the customer may feel they should increase their own expressed level of concern over the problem in order to get more attention from you.

In such cases, the more you appear to brush off the problem, the more they will complain.

Outside of (possibly) some very expensive development processes, it is perhaps inevitable that a bug will sometimes be found after release. But it never needs to be acceptable (or "OK") for bugs to slip through. You can reconcile these two beliefs by making it clear that you don't want to deliver buggy software and that you take the discovery of even one bug as something to be addressed. The next step is to figure out how to address it.

If you make the customer understand that you are on top of the situation and doing everything within reason to fix the problem, they may complain less. If they somehow inform you of the existence of the bug (such as in an email saying, "Hey, is this supposed to happen?") before the meeting where they tell you how disappointed they are, you might even be able pre-emptively to make them understand (even before the meeting) how seriously you take this situation and in that way possibly deflect some of the criticism.

Improve this answer
4
  • 3
    +1 for the idea that bugs are normal but not acceptable :)
    – sea-rob
    Jul 30, 2014 at 21:35
  • 1
    At what point does the user test the application? Do you supply them a checklist with everything that needs to be tested? You need to give that same checklist to your QA department, then compare both lists before releasing the software. If an item was tested by neither, (why didn't QA test it?), or by QA & not by them, then the client has to sign off on that feature going out untested. It doesn't excuse you from bugs, but it does tend to squash the complaints.
    – Adrian J. Moreno
    Jul 30, 2014 at 21:52
  • The problem with this, in my not-even-remotely-humble opinion, is that it seems to communicate that you can achieve a bugless state. And while I'd agree that you can get pretty darn close -- to the point of the customer not noticing a bug for years, it's also important that the customer take a more "lighthearted" approach to some amount of buginess. There's a level of buginess wherein the developer is being too lighthearted; but it can also be the case that clients incorrectly presume the developer can prevent all bugs and therefore should.
    – svidgen
    Jul 31, 2014 at 2:16
  • 2
    I disagree. I do not feel that being extremely explicit and detailed leads to the assumption of no bugs. I think it leads to 'you can see specifically what we test' and communicates that you test what is important.
    – Michael Durrant
    Jul 31, 2014 at 11:11
14

  1. Agree wholeheartedly with the customer that repeated bugs are a problem

  2. Have the customer agree that more work should be done to prevent these bugs

  3. Have the customer agree that more qa and more testing is appropriate

  4. Have the customer agree that this will initially seem to slow things down a bit and cost more

  5. Do more qa and write more tests during development.

  6. Invoice accordingly

Improve this answer
1
  • F-, steps out of order, invoiced customer with increased cost and they cancelled the project, next time would put upcharge contract options, with increased costs, in front of them as a decision as soon as possible.
    – Kzqai
    Aug 29, 2016 at 15:45
10

Same as you would to any other customer: "I'm very sorry that you had problems. What can we do to help?"

Now, you're likely not going to be able to do everything they ask, and certainly not for as free as they would like it to be. That's a matter of negotiation. But your first communication is apologies followed up by positive, constructive overtures.

Improve this answer
8

It sounds like you haven't been up-front about the nature of your work with the client from the beginning. I'm not sure from your question that you and your client understand that All software is buggy.

And I do mean all. Even your HelloWorld app is "buggy" if it's expected it to ... I dunno ...

  • Automatically translate based on locale settings
  • Say "hello world" out loud for hearing impaired users
  • Run on a toaster
  • Other unreasonable things

Or even if it's expected to do something kinda reasonable that wasn't initially expected:

  • Display "Hello World" visibly even when STDOUT is redirected to /dev/null

Bugs are often just features as seen from another perspective. If there are delusions about this on either end, clear that up.

BUT FIRST, it's wise to apologize if any of the following are true:

  • The bug is severe
  • The bug is a result of some carelessness on your end
  • If the client wasn't fully educated on your process, the nature of software, or the nature of bugs
  • The client is very upset (even if it's not your fault)

What you do from there depends on your contract and desire to keep the client. If you bill by the hour, it's between you and the client as to whether it's billable time. That may require some investigation on your part before you can determine whether the issue was related to recent billable work. If it's a fixed price for completion of X, you should probably fix it for free. But, nothing is not beyond the realm of negotiation -- even if your in a contract.

Basically, have a conversation with the client and come to an agreement. Speak like humans. Ensure that you're giving the client's needs and expectations explicit consideration. Ensure, in as polite of a tone as possible, that the client also understands your needs in the relationship (to make a living) if profitability on the project is becoming questionable.

And if this is a common occurrence:

  • Educate the client and agree on bug-fix and change-request procedures (and billing).
  • Update your development and QA process.
  • Update your attitude.

Your job is primarily to know what you're doing and deliver high quality work. If you don't have processes in place to ensure the client is getting a stable product, you need to fix that -- immediately. Secondly, but equally importantly, it's your job to politely educate the client when misunderstandings about the work, the product, or the process arise.

Imagine taking your car into the mechanic to replace a battery. Shortly after the replacement, you hear "funny noises" when you turn a corner. When you return with your car, your mechanic will (should) politely investigate the issue, explain the situation, and bill based on whether the newfound noise was related to the battery install.

He probably won't go to his buddies say, "I have a pathetic client", unless you've been truly unruly -- in which case, a good mechanic might offer a refund and recommend another mechanic.

Improve this answer
7
  • I agree with being apologetic. Customers pay thousands, even millions of dollars for software at ridiculous hourly rates. Even if the customer is wrong, being humble is key. Do not risk making the customer angry. Ever. Have a plan ready to fix the problem, even if the problem is one of perception and not code.
    – user22815
    Jul 30, 2014 at 22:01
  • 1
    @Snowman: That's really bad advise. I once thought so too. If the customer is wrong, you need to be very explicit about that, otherwise they won't understand. You will have to press those issues, or the project will grow into a direction where you will no longer become frustrated until you're no longer able to deal with the emotional strain of maintaining the project. Also, for most people, there is nothing ridiculous about hourly rates, particularly in comparison to what people charge for "work" that doesn't even produce anything.
    – back2dos
    Jul 30, 2014 at 23:29
  • I agree with Snowman. Apologize and address whatever the issue is. This doesn't mean that you don't explain the underlying issue in more detail. However it's important to focus on that underlying issue and not how "wrong" they are. Start with the customer is always right and then just point out a few "minor details" that might not have been considered (secretly that can mean all of their points are wrong).
    – Michael Durrant
    Jul 30, 2014 at 23:40
  • @back2dos perhaps I could have articulated this better, the point is to be apologetic and diplomatic. If the customer is angry, saying "you are wrong" is NOT going to help the situation. There are polite ways to calm the customer down and get the point across.
    – user22815
    Jul 30, 2014 at 23:53
  • Maybe it's not clear in my answer: the apology is contingent on the client's expectations having been set wrong or the bug being severe.
    – svidgen
    Jul 31, 2014 at 0:14
2

The immediate answer to your question is to remain professional, but you have to back it up with action. Specifically, addressing the customer's concerns in a way that objective and fair.

It is important to have open lines of communication and an easy way to report and track bugs. Typically this goes through the project manager or development lead, sometimes the customer has direct access to the tracking system (e.g. Jira).

If the customer feels reassured that they can report bugs and they actually get fixed, this goes a long way toward improving their attitude toward both the software itself as well as the processes used to build it.

The important thing is to have a clearly-defined process the entire team follows when reporting bugs, scheduling them to be fixed, and validating they are fixed. Depending on the type of bug this may involve writing more test cases, or manually testing. There should be a clear regression strategy as well in case a bug for which a test does not exist (e.g. spelling error) is broken again later on. Be sure to work with the customer to identify the high risk areas to get the greatest return on investment from your QA.

Improve this answer
3
  • There's the problem that most customers are not experienced software testers who can make useful bug reports.
    – gnasher729
    Jul 30, 2014 at 21:42
  • @gnasher729 this is why there are multiple ways to report bugs, and the team needs to pick the most appropriate one. I have worked with technical users who had access to create bugs (and user stories) in Jira. Normally they go through the project manager (sometimes myself as dev lead) who performs an independent test to validate the bug and rewrite the bug report better than a non-technical user could.
    – user22815
    Jul 30, 2014 at 21:46
  • @gnasher729 see: Getting users to write decent and useful bug reports
    – gnat
    Jul 30, 2014 at 21:49
2

Something that may help is to point out that software development is similar to a production environment. Even the most stringent of environments, such as nuclear reactors, understand that the unknown must be bounded statistically. Their bounds are just tighter than ours.

Explain to your customers that you can bring bugs to an arbitrarily rare level, such as the elusive "6 sigma" that is so popular now days. However, development of large applications at this grade is exceedingly expensive. If they truly value a low bug rate, they are free to pay the cost for it.

Another approach you can take is to create more testable requirements. If they want you to reach a very high level of reliability in your software, the requirements you are given are going to have to be more and more specific. If I am given the requirement

Users should feel the interface is interactive

I cannot reach a high level of reliability. If I am given the requirement

When the user clicks on the interface, it should respond within 0.1 second 95% of the time. In 4.99% of the remaining cases, it should display a 'waiting' icon while it is processing

then I can seek a high level of reliability because I can develop a testing process to mitigate bugs.

As a follow on, I would like to suggest an alternative to seek. Your customer is acting like a customer. If you are given the opportunity, try to work with them to turn them into a partner. The customer/provider relationship is not as stable as the partner/partner relationship. The latter can actually deal with bugs better.

I list this as a follow on because it doesn't really address your question, but I find it is something important to think about when dealing with longer term customers.

Improve this answer
2
  • As an addendum, I know of one proven bug-free piece of software in existence. A while back, some mathematicians codified the L4 microkernel, and used Coq (an automated proving algorithm) to demonstrate that the L4 code worked perfectly (as in "every functions pre-conditions/post-conditions provably matched those in the documentation")
    – Cort Ammon
    Jul 30, 2014 at 22:24
  • If you're referring to this project, then even they had to make some assumptions. Granted, most of that looks like pretty safe assumptions (but I know nothing about kernel development).
    – Izkata
    Jul 31, 2014 at 2:06
1

You are really asking on the wrong website. As a programmer, you don't reply to this at all. Your manager, or better your product manager, or maybe your sales people, they are the ones to reply to the customer.

Now if your manager, or product manager, or sales people, come to you and ask why they have so many complaints about bugs in the software, then the bad answer is "must be because I'm a pathetic developer". The good answer would be "do you remember how we told you that one week testing isn't enough? And how we told you that we shouldn't make these big changes just before the release? And how we told you that we have to spend some serious time improving quality instead of adding more features? "

Improve this answer
2
  • 4
    In an Agile environment, the whole team collaborates: this includes the customer. Having spent many years as a dev lead, I worked closely with many customers. This includes helping report bugs as well as providing a technical perspective to help reassure customers. This is why developers with people skills are so valuable: we know the code is designed in a way to alleviate the customer concerns, and can convey this to non-technical people. Football and car analogies help too.
    – user22815
    Jul 30, 2014 at 21:58
  • 2
    Development methodologies aside, if you work for a smaller shop then you may occasionally be the one interfacing with the customer. It's not entirely a bad thing either. There is a lot to gain from talking with the customer directly. It brings the sort of perspective that a feature specification will never bring.
    – Derek W
    Jul 31, 2014 at 0:51
0

Address the bug, of course, but there are a couple of factors to consider. Remember that at the end of the day it's a business relationship: a value-for-value proposition.

1) Is the overall relationship a good one? Are they using the software? Do they want to continue the business relationship? You might not be able to fix their hurt feelings, but you can certainly focus on positive, forward-looking results.

2) Sometimes people express themselves in funny ways. They talk about the end of the world, but that's just how they talk. (My little girl does that.)

3) They may be apprehensive about addressing the issue. People like the happy path. So their feelings of disappointment may be as much from having to talk about it as having the problem.

4) It might be a negotiating tactic, as in "We'd like you to do more work for us, but we need a discount because of that TERRIBLE BUG IN THE LAST VERSION." OK sure.

5) There may be a legitimate cost concern, as in, how to pay for the time to correct the issue.

I've found in dealing with external and internal customers, if I focus on results, and address any problems diligently, the interaction gets smoother as trust improves. Fix the problem, and take the long view. As you establish the basis of your relationship, you want to focus on the forward-looking stuff.

If nothing else, it's a great example of customer interaction to learn from.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.