When Developers Do Not Work In Production...

...Software suffers.
This will certainly ruffle some feathers. I suspect if I was working in development and did not have any experience with how my stuff worked in production I might take offense.
In defense of developers, it is seldom part of the plan of development leadership to expect their development staff to gain this experience. I am not talking about some afternoon field trip to one of the production customers to be a nuisance looking over their shoulders. I am talking about some real time on the pond. Sitting down with the end-users and asking them what they like and more importantly what they don't like. Getting to know their workflows and how your software facilitates, or more importantly how is impedes their work.
I am not just talking about application development that ends up in the hands of end-users. End consumer of software like Report Writers, Business Rules Engines, BI software also needs some TLC.

For example, years ago I worked with a Report Writer that in the interest of maximal reuse the vendor decoupled the query from the presentation layer. To make matters worse they stored all the queries for every report in a single file. The production systems I deal with can have up to 1500 reports to manage. They might also have as many as 8-10 staff members that write reports. To further compound this the development environment for writing reports is on each report writers individual Windows workstation. The runtime enviroment is on a Posix server. And, workstation and the server had their own, out of sync version, of that one file that held all the queries. Meaning...

• We (actually, us and our customers) had NO means of keeping that query file in-sync between all the different report writers working on different reports and queries.

• Further they had no means of getting the queries in-sync with that single file on the server.

As a remedy, we created a special tool that took the query from the workstation query file and appended the query file on the server. In the next two releases of their product that we upgraded to they changed their underlying metacode and broke our tool.

• This approach made troubleshooting and support very difficult.

For example, if you wanted to share a report, or open a case for a report you were having trouble with here was the process you needed to go through.

1. Send them the report file (which contained the presentation layer)
2. Cut-n-paste the query from the other file to send to them. You also had to send them the name of the query (case-sensitive) so they to add it to their environment.

I could go on and on. Needless to say we got them to add functionality that coupled the query with the report. But, the real point I wish to make is that the developers lack of understanding of what it takes to support multiple employees writing reports in an operational environment contributed to what was one of the biggest software fiacos I have witnessed in my 20 years in this game.
While that example is extreme it serves to satisfy the old cliche that "you will never understand until you walk a mile in their shoes."
The #1 problem with software today is the inability to gather bullet proof requirements and translate them into killer apps. While there are many, many reasons for this, one is... that it is hard to communicate effectively with someone that has no experience with the boots you have to walk in.

I do apologize if this offended anyone. Though, it does not change my perspective on this matter one iota.