My argument, yesterday, that how an application is to be used is more determinative of the right toolset for building it than what the application does, embeds the assumption that the people we sell our software or development ideas to, either are end users or make decisions on the basis of end user needs.
The most famous contrary example involves the battle for market share between Microsoft Word and Word Perfect right after the arrival of Windows 3.0. In that situation end users generally loved Word Perfect because it was simple, it was fast, it scaled well, it rewarded learning, and it made efficient use of the scarcest computer resource at the time: screen space.
Unfortunately the people who made software decisions generally didn't type well - and they liked Word first because they loved the ability it seemed to give them to hunt and click their way through the production of simple notes, and secondly because they simply didn't understand document structure; didn't understand that what works for a two paragraph hunt and peck is a productivity disaster for more complex documents; and didn't understand that there's more to a document workflow than punching out a paragraph or two and filing the paper.
Basically what happened at the time was that Microsoft recognized who their customer was and provided what he wanted - to the customer's long term detriment and Microsoft's profit. Good for Microsoft, bad for productivity and the American economy - it takes longer to produce a note using MS-Office on a quad core now than it did using Word Perfect on an 8Mhz Tandy PC in 1986; but hey, it's history, right? so who cares?
Well, you should because most of us face similar moral choices every time we initiate a new development project or software purchase. The problem is this: the people we need to pitch the proposals to first aren't usually the end users, and the extent to which we pitch the proposal to meet needs that end users don't share, is the extent to which the project starts out counter-productive.
In the past the off-setting argument has been based on the idea that standards lead to efficiencies: that corporate standards for things like data management and development software have to be enforced independently of application design and user needs because doing anything else creates huge long term maintenance costs.
What that argument really says, however, is that the enforcement of corporate IT standards has a greater value for the business than does selectively abandoning those standards in search of greater user productivity - or, in practice, that the savings produced by adhering to standards exceed the productivity gains that come from abandoning them.
That argument certainly makes sense for the data processing, System 360, world because costs are high and the impact of change on user productivity is low, but it doesn't hold for the Unix enterprise because the costs of change are minimal and the productivity gains possible quite high.
In other words, when we assume that the people we pitch our projects to won't accept development tools other than those meeting pre-existing corporate standards what we're doing is meeting their assumed agendas rather than those of either the users or the business owners.
Obviously, acquiescing to this kind of mistake is the pragmatic thing to do - after all, you're not going to get the go ahead on a Progress project in a committed dot.net environment - but it's also dead wrong on both moral and technical grounds because the development toolset ultimately determines everything about how users see the application and while your bosses may care about whether you use Eclipse or dot.net, DB2 or MySQL, TCP or UDP, users don't. What they care about is the interface: what they see, how it works for them, and all of these things are artifacts of decisions your bosses have made and you've had to agree to entirely without reference to either users or the application.
So what's the bottom line? for users it's ultimately about what the application lets them do, not the technology behind it - but to get the project approved most of us have to completely reverse this: picking the toolset without any reference to what that toolset will produce for the user - and that's just plain backwards.