xnfec is on to one of the core problems with "give it to me fast, cheap, and working". You just can't do all three.

One of the key issues I've seen with doing quick and dirty barebones proofs as a "demo", is that they *always* end up in production just the way you finish them. The "we'll fix it later" mentality that supposedly accompanies these projects turns into "that works just fine as it is" (with its un-normalized Access database running on Susie's machine in the break room), and then you're off and running to the next whim that the business users come up with. You never get the chance to go back and re-do that application correctly. Further, six months down the road when that crap-app is losing data, has totally farked up all of its primary keys, isn't actually working the way they thought it did, the Ambulance Chaser that wrote it is nowhere to be found, and the company is having a complete and total meltdown, people get incensed when you tell them that it will take weeks or months to fix it (and the data may be gone for good) instead of the few days that a properly developed app may have taken had it been done right in the first place.

While I can certainly see the business users' distress at their great new idea taking longer than they'd like to implement, I also agree that many applications are over-engineered for the sake of over-engineering (or for the sake of using that shiny new technology). I do think that a balance can be struck between sticking to some good core design principles, building in a touch of scalability (but maybe not that full-blown effort you'd like to do), and that the app can be kept under the aegis of KISS to satisfy the need for faster development time, but also making a little time for ensuring data integrity, some amount of scalability, and ensuring that you have an app that is functionally sound. The key is having strong project managers or lead developers that are able to sit with the business users and strike that perfect balance.

I've been the victim of a department hiring some outside yahoo (the guy wasn't even skilled at his job), and then getting incredibly angry when we denied their out-of-the-blue requests for unrestricted access to some of the most sensitive data we had. In point of fact, we had no idea they had even hired this guy, no clue what project they were trying to embark on (it turned out to duplicate almost perfectly our already underway data warehousing initiative), we just knew that they suddenly wanted su level access to our databases. Of course we said "absolutely not" when they refused to even provide us with a reason that they needed that access. The first we heard of their project was when we were pulled into a meeting with the entire pantheon of top executives for a chewing out for being "territorial" and "obstructionist". It was a mess.

Certainly the key is in good communications between stakeholders and IT management and architects/leads. The business users have to understand that good IT staff are working to ensure the company isn't sued into oblivion/can pass IRS/Security Audits/can keep the IP safe and intact, and IT users have to understand that business users are trying to hit that next big thing before the competition does to keep everyone's paycheck coming every two weeks. If both sides can understand the challenges that the other side is facing, a balance can certainly be achieved to satisfy as many goals are possible between the two groups.