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?
How do you respond to: Ever since the update... questions from clients?
customer relations;software updates
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.Do you develop against adatabase that is the same size(roughly) as production? If not thenyou will always have these problemsbecause queries that are fine withsmall data sets are often dogs withbigs ones.Do you load test in QA? Whatworks fine with one user testing isvery different from how things willrespond with 1000 users trying to dothings at the same time.Do you assume the user'sperception is wrong and treat themlike they are stupid forcomplaining? If so, then yourattitude is causing more complaintsnot lessening them.Are you doing a good job oftesting? Do you regression test features not changed to see if they are affected by the change? Do you even care how longthings take until they hit prod?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?Do you have environmentaldifferences between dev and prod.Sometimes those pesky differences inoperating systems or databaseversions will cause issues like thisas well. It is often a good idea to have a staging enviromnet that is exactly like prod, some equipment same operating system, same database with dat that is as close to prod data as possible. This is used to test your deployment. Run it first on this server and tehn have some users or testers go to it and run through some tests. How good is your deployment process,do you often miss steps?  Can it berun by someone other than thedeveloper because it is clear whatcode goes in the branch you aredeploying? We got a lot better atdeploying code when we got aconfiguration management team andnobody had the rights to sit withprod and babysit it making oopsiechanges. Automating your build can help tremendously. No one should be guessing what needs to go to prod as it should have gone to QA and staging first and any deplyment issues worked out. Scripting database changes is key too. They shoud be in scripts and in source control, so the build process can pick them up without someone having to remember, oh yeah, we need to change the length on Column B to 241 from 50. I find that people often forget to treat database changes as code preferring to use the GUI which is virtually always a bad idea on prod. 