Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ziggy (25)

ziggy
  (email not shown publicly)
AOL IM: ziggyatpanix (Add Buddy, Send Message)

Journal of ziggy (25)

Friday September 01, 2006
11:53 AM

The Safety-in-Numbers School of Software Design

[ #30841 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • DHH totally glossed over the two criticisms (unicode and speed).
  • I agree with most of what you say, but there's one thing you said that really jumps out at me:

    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 unnam

    • 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