So a few of the passionate conversations here at the MVP summit have been around sacrificing testing when a deadline looms. Apparently this is a common practice amongst MVPs which I think a lot of us were quite surprised at.

D'arcy, Rod, and myself were talking about this at lunch so I thought I would add our thoughts to the mix:

There are a few things you can do when under a looming deadline:

Add Resources
By adding resources to a project you can get more done in more time.... in theory. Granted there is only so much a new person can do. They have to be interviewed, trained, and not be a drag on the team. Adding more resources could actually cause you to not meet your deadline unless a lot of foresight and careful consideration is taken into place.

Cut Features
Its much easier to hit a deadline when there is nothing to do. This is usually one of the best options to give your clients I/we feel. A client is usually happy to delay a small / lower priority item in order to get the higher priority items on time. Then follow up with a small release with the one feature or simply move it to the next cycle/release.

One "feature" that lots of people cut is security. Security is an easy thing for people to think of dropping as when you remove security from the application, the application still works and has all the functions the user wants. In my experience when security becomes a second class citizen it never quite comes back to the same level it would be.

Cut Quality
This is the debated one. If you just throw testing out the window you are more than likely going to have a buggy product and on the next cycle will spend lots of time fixing/managing/coordinating bugs which make that cycle take longer (so we should cut more quality out so we can spend time fixing issues from the last time we cut quality). This is usually quite a short sighted view in our opinion.

Push The Deadline
This is often the one that is not thought about. Why not delay for a week or two to get this out? What we are doing usually does not have peoples lives depending on it (even if it did I am sure we would want it to be right rather than right on time). The thing here is to manage expectations. Tell your consumers as early as possible that there might be a delay and that we can either be late or remove features (or remove quality apparently although I/we don't agree that is acceptable usually).

Wording
A few funny sayings/wordings came out of our chat:
"Drop testing? Sure we can drop quality. Not a problem."
"I want a car tomorrow. I know it will catch on fire half way down the street but we can patch that later right?"
"If our coders don't produce quality without tests then we will just replace the coders until we get better ones. They are in infinite supply after all"