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

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.
  • 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 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.