Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Ever since the update, people keep calling and saying "Ever since the update X, Y and Z are slow, bad and crashing"

This has happened ever since the dawn of updates.

What do people expect? Gamma comes after beta, and gamma testing always turns our users into The Incredible Hulks...

Perhaps you've never heard this from a client, perhaps you're in college or a FLOSS Dev who can spread the blame around more than 5 or 6 guys, perhaps you unit test your code, perhaps you're not in that interesting situation where customers actually call you requesting the exact time of day you'll be releasing today's patch (I'd love to do that to Microsoft) or perhaps you're a sorry son-of-a-biscuit like me who just shipped a new update and went home and is dreading going back to work tomorrow.

Anyway, ya'll are smarter than me anyway. How do you field criticism framed in "You must be a bad programmer because you're making your software worse"?

share|improve this question
    
It always happens for me whenever we roll a sprint to PROD –  Tech Jerk Oct 6 '10 at 4:54
    
Having some lightweight profiling that's always-on can help (as part of a larger strategy). "That's funny; the data show the page is being generated 5% faster now. Which part exactly feels slow? Maybe we can do something about it..." –  fennec Oct 6 '10 at 5:13
    
The question is really if X, Y and Z are really any worse tahn before, or if there is some other factor beyond your control at work. –  Gerry Oct 6 '10 at 21:21
add comment

6 Answers

up vote 5 down vote accepted

If this happens to you every time you deploy, there could be a serious flaw in your development process. I would suspect a couple of things that are causing the problems.

  1. Do you develop against a database that is the same size (roughly) as production? If not then you will always have these problems because queries that are fine with small data sets are often dogs with bigs ones.
  2. Do you load test in QA? What works fine with one user testing is very different from how things will respond with 1000 users trying to do things at the same time.
  3. Do you assume the user's perception is wrong and treat them like they are stupid for complaining? If so, then your attitude is causing more complaints not lessening them.
  4. Are you doing a good job of testing? Do you even care how long things take until they hit prod?
  5. Do you pay attention to when is a good time for the users when you deploy or do you merrily deploy a change to the accounting system the day payroll is run and wonder why users are angry at the slow down?
  6. Do you have environmental differences between dev and prod. Sometimes those pesky differences in operating systems or database versions will cause issues like this as well.
  7. How good is your deployment process, do you often miss steps? Can it be run by someone other than the developer because it is clear what code goes in the branch you are deploying? We got a lot better at deploying code when we got a configuration management team and nobody had the rights to sit with prod and babysit it making "oopsie" changes.
share|improve this answer
    
Good points: 1. Yes, 2. Sometimes, 3. Pass, 4. N/A, 5. Not if we can help it. I have a question for you, but I might think about it and post it later. –  Peter Turner Oct 6 '10 at 21:12
    
6. Sometimes, but those are legit bugs usually caused by something in an old update not having been run. –  Peter Turner Oct 6 '10 at 21:19
    
7. Yeah, that's a big problem - no one utilizes the makefile I wrote unless it's absolutely necessary and this is the cause of 60% of our woes. (P.S. I'll mark this as right if you format it better) –  Peter Turner Oct 8 '10 at 13:37
add comment

How do you field criticism framed in "You must be a bad programmer because you're making your software worse"?

But such criticism is mostly justified. A new release should not be worse than the previous, but as we know, in reality it often it is, and it is our fault because we made it.

Making mistakes is human, and it doesn't make anybody a "bad programmer", so don't take the criticism personally (I would never take any professional criticism from a non-colleague seriously anyway). Just thank the customer for reporting the issue, and fix it as soon as you can. It's your job as a good programmer.

share|improve this answer
add comment

Well, at work we don't interact directly with the clients much, so I'll have to answer this one from personal project work. I'm writing a game engine that people can use to build their own games. It's still in pre-alpha, but I've got a few interested users, and sometimes I get bugs.

When I get a report like this from a user, I try to use the personal touch. I didn't mean to introduce bugs, and I want them to have a good experience with my engine, so I need to make them believe that. First, get an IM handle so we can talk. I'll ask the user about their project and try to get a copy of it. This makes reproduction a lot easier. Ask them what they were doing when the glitch occurred. Meanwhile, I've got the engine open in the debugger and I'm homing in on the issue while we're talking.

If it's an exception, it's usually pretty simple. Reproduce the issue and the debugger grabs it and takes you straight to the error location with a full stack trace, and it's obvious what's going on. If it's slow performance or incorrect behavior, it might take a bit longer. But in most cases I can have a fix ready within the first 20 minutes, tops. I zip it and send it to them to test. "OK, I think I got it. See if this works at your end?"

The response is almost universally some mixture of amazement and gratitude, because most developers (read: software companies) just don't fix bugs and rerelease that fast. And then, if it's actually fixed, I've turned a potential critic into a fan. It's a really good technique; I just wish more developers would adopt it.

share|improve this answer
1  
Yeah, they are amazed. I work with a lot of nurses who log onto our PHPBB forum and use the 'Bang's head against the wall' emoticon, then wind up thinking we're pretty hot stuff once we've transferred a DLL or ran an SQL query and their system is working again and they didn't even have to log off. –  Peter Turner Oct 6 '10 at 4:43
add comment

I personally take the problem positively. I do interact all the time with a lot of customeers, and I still code too.

When they download a new release and tell me something like that, I always say something like this:

Thanks for reporting me that bug. Maybe it has been introduced together will all the new features we added. We'll fix it asap.

In fact, the customer is your real boss. If the experience with you is bad, it's bad for you too.

Even if he is not right, you as a part of the company, you should take this opportunity to:

  • learn from him, by collecting potential improvements you could make to the product.
  • convert an unhappy customer into an happy one, so happy that he will talk about you around (including your boss)
  • be proud of what you are doing
share|improve this answer
1  
"convert than unhappy customer into an unhappy one"? I wouldn't want to do that. –  Lie Ryan Oct 6 '10 at 9:07
    
Lie, thanks for that. I edited my answer –  user2567 Oct 6 '10 at 9:38
add comment

Step 1 is that you must come from a mindset that this (the update breaks other stuff) is not normal. Your update should not break or slow other parts of the app. It's not ok, it's not to be expected, and it's not the user's fault when they complain about it. You should be doing as much testing as you can to try to prevent it. When it happens you have a problem, and an urgent one.

Step 2 is that you must know what you did. Your source control system might be able to help you, or some kind of work tracking system, but you must be able to say the minute you get one of these complaints "ok, I added a column to this table, changed this grid to calculate the new taxes, added those two new reports ..." and so on.

Step 3 is that you must have experience finding perf issues and crashes quickly, so you know what sorts of things are likely to cause them, and can get to the problem right away. This thing has gone live and you must find the problem quickly and get a patch out. Changing a report can't slow down a part of the app that doesn't use the report. You are in emergency mode now and have to figure out where the mistake is and what to do about it - without breaking another part of the app in the process.

Step 4 is for each one of these miseries, you should learn a lesson that you will test for next time. You will become "that guy" who objects to certain constructs because "that will be horrible when there are 10,000 records".

A little more on the "this is normal" front. I run (among all the other things we have going on) an agile project for an external customer. We've been doing releases roughly every 6 weeks for two or three years now. And yes, the release is scheduled to the minute. We just did one at 8am yesterday. And roughly every 4th or 5th release (once or twice a year, in other words) something gets broken live, and we leap into action and make it right as quick as we can. Even though we test and test and test before the release. Then we tell them what happened. "There was a little bug in the June deploy that let this field be blank, but we never noticed because we weren't using the value at that time. Then in this deploy when we started using the field, the ones that were blank caused that error message you saw. We've fixed the bug so they can't be blank, put values in the bad records, and confirmed that it doesn't blow up any more. Our apologies." Or "That emergency change you begged for, just two days before the release, had consequences we didn't think of and didn't test for. Remember why we resist emergency changes?" I may not be a bad programmer for making it worse with the update, but I surely did do a bad thing. And I need to make it right.

share|improve this answer
add comment

Details, Details, Details. I ask what they were doing and when, be specific. It could be something or it could just be that the Justin Beaber video just released on youtube. Log files are your friend in both cases.

I also ask for dates when they noticed it. Sometimes especially in enterprise shops users don't know when a release comes out, they just know that something takes a long time to complete and they are just now complaining about it.

Job Shadow. Can't emphasize this enough. If you are lucky enough to have users nearby, just watch them work from time time. I often find they ignore glaring issues and never report them. They will often only complain when they know something is new or they initially notice an issue.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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