 |
| Richard Riehle in Office Space |
I have been killing some time by catching up with http://clientsfromhell.net, and I was almost depressed because a lot of the stuff that is supposed to be funny, well, isn't. It is hard to laugh at so many dumb things that I have actually experienced in real life.
Then I saw this one:
Me: “Here are the designs, and, with your approval, we’ll code them and put them up in a couple of days.”
Client: “Why aren’t they up now?”
Me: “We require client approval before we put up the final product, in order to make any changes.”
Client: “I wanted it up yesterday.”
Me: “Well, this is the first time that we’ve had a chance to meet in person and go over the designs.”
Client: “But I wanted it put up yesterday.”
Me: “I had emailed these to you for approval, but you never responded.”
Client: “I thought you would just put it up.”
Me: “Not without your approval, sir.”
Client: “Well, put it up.”
A week later.
Client: “You know what, there are a few changes I need you to make… I can’t believe you put that up.”
This actually happened to us a few times, to the point that we now force ALL of our customers to specifically direct us to update code on a production site.
We have a hard rule about production services: you will not shut down a server, restart a server, update code, rollback code, change configuration parameters, change database schema, change data-driven configuration data, etc. unless you have written instructions from the customer in the following format:
"Please post/move to production [whatever] to the production environment for [project name] on date such and such."
The whatever is usually an agreed-on unit of work, it could be a full project, or a seasonal promotion, or a bug fix, etc. If we don't get these instructions, we don't touch a production environment. Whenever a new customer is briefed into our process, we explain this to them.
Why? Because when somebody makes a mistake and he/she has to pick between throwing himself under the bus, and throwing a third party employee (you) under the same bus, human nature makes them lean towards throwing you under the bus. The hand off email keeps everyone honest: the customer is giving you specific instructions that cannot be misunderstood, and you are receiving instructions to modify the live environment.
This may not feel like much to open source hippies and people that think that the only thing websites are used for is as blogs, but this is life or death stuff for the other 99% of the work that is run from a website. Imagine a programmer screwing up and posting a new code version to Pay Pal or eBay, without proper permission. Posting the wrong version of one of these sites to the production environment could cost these companies a ton of money, and it could easily cost the programmer's employer a huge lawsuit.
Imagine the same poor bastard programmer posting the wrong version to the IRS gateway that receives ALL electronic tax filings for the country, on April 13 and the system goes down. Can you imagine the complete and absolute mess that something like this could create? This is why no programming company in its right mind will allow live updates to be posted unless the customer gives them written approval.
If the deployment is still bad, the programming company takes the blame for delivering bad code, but the person at the customer company that handles the project now has to answer to the company as of why the hell the deployment was approved if it was clear that it wasn't ready.
Comments
Post a Comment