Throughout my career I had worked at companies that had a collection of different environments for different purposes. We always had more or less our desktop environment, a test environment, a QA environment, a staging environment and a production environment. This went for both servers/applications and any data sources we were using.

When I started at my current company I found that 90% of the apps were either developed on a desktop environment against production data sources or developed directly on the production server depending on the platform. This wasn't particularly surprising, as I was hired in part to make changes to improve the way the development team functioned, which was clear from my interview process. We slowly started to turn the philosophy and pretty soon, most of the apps could be run in either a desktop, test or production environment. Not too long after that staging came around as well.

Now most of our developers see the benefit of this methodology and defend it vigilantly. However, we have a number of legacy apps that never got migrated. We also have a number of legacy programmers who think of this as a waste of time. Unfortunately, we got lip service but never full buy-in from management. We got what we thought was a commitment to invest substantially in this about a year ago, but nothing materialized despite the considerable planning that we put into it. Now we are finding that we need more and more environments. We need help from the server/network administration teams for setup and we need participation from the business stakeholders to support the release cycle. We are at a place now where a project can function what reasonable developers would consider "normally" only if you have the right people on the project and the time to set up the proper environments.

I'd love to present a complete argument, but management really has no time and interest in hearing me out until there is a critical issue. I can't really articulate the benefits simply as it always just seemed second nature to me. I was wondering if there are any good, simple, irrefutable reasons for the separation of environments that would get managers lacking development experience to support this idea?. Are there any good resources/literature on the topic?

The answer: Money

I don't care what the actual reason is. Money MUST be at the root of all of your reasoning, especially when dealing with management.

If we both sat in a room for 2 hours, we could come up with dozens of reasons why it is better to have multiple environments.

Here's the problem: If the reasons are not based on money, then none of them matter.

Programmers are not hired to be smart. They're not hired to be creative. They're hired to increase revenue -- either by earning money or saving money. If you're not doing either one of those, you'd better get your resume together.

When looking at it from that standpoint, the answer is simple: 


  Having only one environment increases our downtime and results in
  lost revenue. Multiple environments allows us to protect our profits
  by giving our users a front-end that is just as reliable and
  dependable as our company.


Repeat it every day.



There are some great comments below that add some real value to this answer, so I'll mention them:


Karl Bielefeldt had a great point when he mentioned that Cost/Benefit analysis is an important factor. An economist might refer to it as the opportunity cost of pursuing multiple environments. While it may be surprising to hear, there are scenarios where multiple environments may not be the answer! If the website of your company is a very minor addition, then unexpected downtime may actually be the more cost effective way of doing business. This doesn't sound like the position you are in, but it is worth mentioning.
BlairHippo had a good point in that you should feel free to make it seem like a catastrophe (and if you lose your data, it is!). Liability is a great tool for persuading managers, but still for the same reason--lawsuits are expensive. Avoiding them saves money.




As an addendum, I found this article to be quite good. It doesn't directly answer your question, but enables you to recognize how programmers are viewed to management, which in turn, leads to this answer. Good read.
