It's like when your telco, cabelco, or cell phone company offers 50% discount for new customers for the first year just to get them in the door. As for loyal customers who have been paying unjustifiably high bills on a regular basis, they don't get a cut; as a matter of fact they might see price increases to subsidize those new customer discounts.

It's precisely because infrastructure code is not visible to the end user that you have to sell that (supposedly elegant) infrastructure some other way. You need to explain what's going on behind the scenes and why it is important on the long term. Upper management will appreciate simple block diagrams explaining that this kind of infrastructure will give them a lot of flexibility and maintainability down the road, reducing the cost of change and bug fixes.

Documenting the backend is also important for other developers who will maintain this code after you. I've had to deal with hundreds of thousands of lines of code with no documentation whatsoever, and it's not pretty.

Finally, I want to mention that not giving the GUI enough attention from the beginning is not good also. I'm a believer that function and form are closely tied together. You can design the best infrastructure in the world, but slapping a GUI on top of it as an afterthought will result in crappy user experience. Also there are a lot of times where certain UI functions, although may seem trivial, actually translates to significant backend design changes. As you mentioned, the GUI is what the user interacts with, and to them it's actually the GUI that represents the application, so it *is* what the application is about to them.

Another alternative to Adobe Reader and Foxit Reader is PDF-XChange Viewer:

http://www.docu-track.com/product/pdf-xchange-viewer

It behaves like Adobe Reader in that it shows you a warning, unlike Foxit. Given this fact I recommend switching to it from Foxit (at least for the time being).

It's lightweight, fast, and has lots of nice features. It even allows you to save filled forms!

If you avoid using anonymous functions you sacrifice the power of closures.

In most enterprise applications you'll be using multiple languages whether you like it or not:

- A multi-purpose high level language for n-tier apps (data access, domain logic, presentation): Java, C#, Ruby, Python
- A database language: SQL
- Web interface (if it's web-based): JavaScript, DHTML, Flash
- Integration and Middleware: XML

As long as you're within one product boundary, one general purpose language is the way to go. Across products (from same vendor or from different vendors): different languages + well standardized protocols (XML or binary serialization) is the way to go. Mixing more than one general-purpose language in the same product is usually a bad idea IMO (unless the languages share a common framework; e.g. C# and VB.NET)

The thing that ties everything together, whether using one or more languages is the development process and tools:

- Source control (SubVersion) -> provides change tracking, branching, merging
- Automated build environment (Ant, NAnt) -> can build code, database, tests with the push of a button
- Continuous Integration (CruiseControl) -> detect and fix integration errors early
- Unit Testing (xUnit) -> ensures predictable behaviour in the face of code changes
- Bug tracking (Bugzilla) -> track defects, plan fixes
- Documentation (Wiki, DocBook, code comments) -> inform your peers of your public APIs (i.e. how they can use what you have written), and possible extension points (how you can use what they have written); inform stakeholders how the system works (concepts, architecture, business scenarios); inform your users how to use your system properly

A good project manager ties everything together and keeps everyone on schedule.