Considerations

Enterprise development has three main components:

1. Development standards
2. Change control standards
3. Documentation standards

These each bear discussion, but the latter two are in many ways obvious; and where they are not, they are highly subjective for a given organization. Let me expand these components briefly:

Development standards include choice of language, requirements for interacting with other code (e.g. libraries, IPC), vetting of technologies and modules, and choice of methodology. This is primarly what this meditation is about.

Change control standards deal with language and interpreter/compiler versions, library versions, source control systems, coding styles⁰, and deployment methods. In general, I support use of the most recent well-tested and stable versions, and the use of a good merging source control system (often CVS¹).

Documentation standards address content and style of in-code comments, user and technical documents, documentation of third-party modules, publishing standards, and so on. I tend to recommend established best-practices for each chosen language -- e.g. use Javadoc for Java code, POD for Perl code.

I mostly want to focus on choices of language for this Meditation.

The Language Trilogy

Lots of managers think it would be great if there was a single language that was an ideal candidate for all enterprise software development. Such a thing doesn't exist, and I believe that it can't (and shouldn't if it could). So, a variety of languages is a necessity in most organizations. The question becomes "which ones?" Consider the requirements:

1. Complete. An enterprise langauge needs to be, at least in theory, capable of expressing the solution to any class of computing problem. In other words, Turing-completeness is a good start. The ideal languages would have pre-built features that represent a broad range of solution spaces as well. Finally, complete languages have readily-available mechanisms to deal with current technologies (e.g. XML parsers, network support, database classes, etc.).
2. Readily available. The language, its interpreter/compiler/SDK, its documentation, its class library, etc. need to be easily and relatively cheaply available to developers.
3. Established. A chosen language should have a bit of history behind it, and have been tested reasonably well -- it's important to have confidence that the underlying system has as few bugs as possible. Additionally, the language should have a well-established community, and good availability of educational materials (books, and such). Perhaps most importantly, the language should have attracted a reasonable pool of skilled developers. This last will be essential when it comes time to hire replacement team members, or to engage maintainers in the future.
4. Multi-platform. An enterprise language should be able to work across the enterprise: and that means it should be available on every platform that exists in the organization. It should be relatively easy to write cross-platform code, and just as easy to write platform-specific code where it's required (such as automation of administration tasks). This is probably the biggest challenge, as there are always niche platforms that pretty much require their own language environments (AS/400 and RPG are an excellent example). It's also the primary reason why a single langauge isn't appropriate, and why every sizable organization occasionally steps outside the chosen set of languages.
5. Testable. Any enterprise language should have an existing testing framework that makes it relatively simple for developers to practice test-driven development and perform automated regression testing.

There are dozens of languages that fit the bill to some extent. While it's necessary to combine languages to achieve all the requirements, it's desirable to minimize the number of supported languages from a management point of view.

Most organizations of any size have some combination of UNIX-alikes (UNIX, Linux, BSD, etc.) and MS-Windows. And, they have a combination of web/server, desktop, and script environments².

Java is immediately appealing: it meets all of the requirements to some degree, the framework itself costs nothing, and the available tools for web and desktop application development are excellent (think Eclipse {free} and RSA, not to mention Ant and the like). The spec for the language is open and a ratified standard. Sun is even moving toward open-sourcing the kit. Plenty of developers are available, and the nature of the language (and available tools) provide some measure of protection against mediocre developers.

Java, though, tends to be slow at runtime (well, mostly during startup). Besides that, it runs up against a wall when doing things in script environments. Yes, you can shoe-horn it, but it's not easy to write, say, Windows automation in Java. So, while Java is a good choice, it isn't a complete one.

Many organizations turn to the .NET framework to address their Windows needs. This is largely a result of an object model that makes Windows features available to developers in a way that a language like Java just isn't intended to. .NET languages satisfy most of the enterprise requirements, and their ability to rapidly solve Windows-specific problems is simply a requirement in most organizations. C#, while somewhat unweildy, is a good choice to complement Java -- the syntax and program structure are so close to Java that Java developers can often be retrained as C# developers in short order. This allows better management of a development staff, as you can have cross-functional teams allocated to whichever dev group is in need at the moment.

But, with C#.NET and Java, you still have rather large frameworks. And, while C#.NET works very well in Windows scripting environments, it doesn't do the job on other platforms. Add to that, both languages are horrible for the "quick one-off" applications that solve so many business problems in the typical organization.

Unfortunately, most organizations I've had the opportunity to work with can't see that shortcoming. They've standardized on the .NET and Java platforms, and when problems inevitably arise that don't fit the development model or capabilities of these systems, the dev team steps outside them. And, as a result, you wind up with a huge tangle of scripts in four different UNIX shells, the abomination that is WinBatch, and some obscure language-du-jour that one particular developer has been playing with.

Enter Perl³. Perl meets all of the requirements for enterprise languages. It's a little harder to find quality Perl developers than for Java or C#.NET, but still relatively easy. And, Perl fills the hole left by the giant .NET/Java machines that are most corporations' development groups. It works in all the necessary environments, and it really shines in the script environment. Its ability to cross platform boundaries with ease, its huge library of existing solutions to common problems⁴, and the ease with which it can be tasked to handle a range of problems make Perl an ideal addition to the common .NET/Java platforms.

Conclusion: My Point At Last

The desire to standardize development platforms in the enterprise is an understandable one. And, choosing the Java and .NET platforms -- as so many organizations do -- is a wise first step. However, it's insufficient to solve the full range of business problems across the majority of enterprise platforms.

To truly have a complete standard framework, an enterprise would do well to adopt Perl in addition to Java and .NET.

A Note on Advocacy, or Why I Wrote This Meditation

I consider myself a Perl advocate. However, advocacy in general tends to turn into zealotry, which in turn ignites a sort of techno-jihad, which ultimately results in harming the reputation of that which one set out to advocate. I think this often stems from a personal ego-attachment.

However, I think an important piece of this Perl-advocacy-cum-zealotry phenomenon is the desire to see Perl replace such popular langauges as Java and VisualBasic. The problem is, managment has seen a business benefit from using these, and are unlikely to switch away from something even on the merit of technical superiority -- much less so on philosophical superiority, which is where the bulk of Perl zealotry lies.

This meditation developed as a sort of expression of how I see Perl from a management point of view. That is, I see Perl as a way to augment the gains management sees from their established platforms. If organizations can be convinced of the value Perl has as part of the Enterprise Language Trilogy, then the Perl community has an opportunity to demonstrate how often Perl is a good choice. This, I hope, would help to undo the years of "bad blood" Perl has somehow accumulated through zealotry and very bad, very public Perl scripts.

Footnotes

0. Coding style is part of change control because it's largely, to my mind, enforced for the benefit of future maintainers.
1. CVS happens to be my source-control of choice, but I'm not particularly tied to it: I strongly believe in using whatever the dev team is comfortable with, so long as the important features (multiple checkouts, merge process, etc.) are there.
2. By "script environment", I mean non-interactive applications and minimally-interactive administration tools.
3. I know, I know -- finally. ;-)
4. CPAN, of course.