Joel's latest essay on writing big enterprisey apps boils down to two pieces of advice:
The safe answer, for the Big Enterprisy Thing where you have no interest in being on the cutting edge, is C#, Java, PHP, or Python, since there's so much evidence that when it comes right down to it zillions of people are building huge business-critical things in those languages and while they may have problems, they're not life-threatening problems.
That, and anything other than those four choices for a platform are "unsafe". So pick whichever one you are most familiar with, and run with it. And, if you really want to try Ruby on Rails, do it in your dorm room, where it doesn't matter when you fail to scale up. :-)
Of course, you know the drill by now. Insult Rails on a high profile blog, expect an immediate response from DHH pointing out exactly where your arguments are categorically wrong because, as we all know, Rails is the best thing ever done with a piece of software. :-)
For my money, both Joel and DHH miss the point entirely. It's not about picking the popular tools that the corporate developer lemmings have blessed as safe. It's not about taking throwing PhD's into a room, giving them Lisp, and expecting great things. And it's not about the war between static and dynamic languages, dumb vs. crafty frameworks, or convention vs. configuration.
It's about understanding the problem, understanding the tools, and building an appropriate solution.
If you take Joel's argument at face value (and that's all it is, a philosophical statement devoid of data or a provable hypothesis), and look back 10-15 years ago, you'll find you have an argument in favor of the status quo: large, mission critical apps running on DOS/Win3.11 + Netware, written in dBase, FoxPro, Clipper, or their ilk. These tools were simply not up to the job, yet as demonstrated by countless unnamed "enterprise" projects, they were suitable for any big enterprisey project.
Yet these were the worst kinds of tools for these jobs. Or, rather, these weren't the tools you really wanted to solve these problems, but they were the best that was available for the slow, underpowered machines of the day. And they sucked. And everyone knew they sucked.
What was the answer? Move away from DOS, move towards Windows (3.x), and client/server programming environments. Brand new and obviously better solutions like SQLWindows, PowerBuilder, Visual Basic, and I forget what else. (Even Smalltalk was a contender for a small number of projects as well.) And if you didn't want to risk an unproven language, an unproven RDBMS, an unproven vendor on a big important project, there was always C and C++ on big iron Unix boxes working with CORBA ORBs. Or, if you were really daring, C++ on Windows with COM (soon to be new and improved, once 32-bit Windows stabilizes).
But were any of those choices the answer? No, not a one of them. (Except VB, which, when adopted widely, wasn't the same language or environment as the anemic offering available for Windows 3.x.)
The lesson here is that the solution blessed by masses of corporate lemmings, isn't always the right one, and the obviously better pitched by Vendors Who Know isn't necessarily the right solution either.
It turns out that the right solution here was the web. And it took a decade to discover, adopt, figure out how to write webapps, and wait for the browsers to be debugged enough. Once everything was in place, we all could move away from the slow, buggy, kludgy, enterprisey development projects that really weren't as solid as they needed to be, and start talking about more fundemental problems, like how to model your data properly.
If you take Joel's argument at face value (and that's all it is, a philosophical statement devoid of data or a provable hypothesis), and look back 10-15 years ago, you'll find you have an argument in favor of the status quo: large, mission critical apps running on DOS/Win3.11 + Netware, written in dBase, FoxPro, Clipper, or their ilk. These tools were simply not up to the job, yet as demonstrated by countless unnamed "enterprise" projects, they were suitable for any big enterprisey project.
Where I worked, in 1991-1996, only maverick grass roots kinds of organizations proposed these tools for large enterprise projects. They typically tried to scale up their successes with Departmental level apps using this kind of technology, usually against the objection and resistance of centralized IT departments.
Enterprise projects in those days were typically done with Mainframes and green-screens, or maybe Unix/VMS systems with Oracle/Sybase databases, but not with PCs.
Re:Large mission critical apps?
ziggy on 2006-09-03T03:31:40
Where is it that you worked 10-15 years ago that these tools were regarded as suitable for big enterprisey projects?A couple of places, actually. xBase was an acceptable platform in small business for records management and billing; I saw it used frequently in medical offices. But the projects I remember most were in finance, where these systems were managing multi-million dollar positions. These were also systems that were sold to multiple clients, in multiple banking centers around the world.
I didn't personally see xBase and its ilk managing 'large enterprise projects', as in the kind of stuff used corporate-wide for a Fortune 500 company. But these are also the same kinds of projects that are held up as 'big', 'mission critical' and 'enterprisey' today, so there's no reason to be overly circumspect on how these vague terms are used.
Where I worked, in 1991-1996, only maverick grass roots kinds of organizations proposed these tools for large enterprise projects. They typically tried to scale up their successes with Departmental level apps using this kind of technology, usually against the objection and resistance of centralized IT departments.Some organizations are pretty rigid in what's acceptable technology. Other organizations are laissez-faire. This leads to interesting war stories, when these two styles of organization merge, and the centralized IT department discovers the critical app written in Visual Basic, written by a nursing school dropout who took a 3-week intro to programming course, who thought that running a line-of-business application on their desktop was a good idea.
:-) As a result, the whole 'enterprise-grade' bludgeon is less about the scope of the project (department-wide vs. deployed across an entire Fortune 500 organization), and more about the qualities of the system being developed (failover, scale up and scale out, low downtime, supporting millions of dollars of business, low latency, high throughput, etc.). At least, that's how 'enterprise' is used today, and how I'm categorizing past development projects with the modern meaning of the term.
