The Secret Weapon

Take off your "My primary role as a software developer is the creation of free software for others to use" hat. Replace it for a few moments with your hat of "My primary role as a software developer is the creation of software which provides a good or service to customers." (I assume you don't sell or license this software; the software is a mechanism of producing your product or service.)

Suppose your business operates under a few assumptions:

• Deploying software sooner allows you to generate revenue more quickly
• Your technology choices (language, libraries, and tools) are sufficient to solve your business problems
• Your technical staff has the knowledge, culture, and discipline to write maintainable, deployable code

Does your technology choice matter?

Yes—but what matters more? Code you can deploy today—assuming you can generate revenue from it—is more valuable than code you can deploy next week. Code that exists today—and does what it needs to do—is more valuable than code which may exist.

With that said, quality is important. Code you can deploy today is valuable for today, but if you can't maintain and modify and deploy a new version next week, it's less valuable than code that you can maintain and modify and deploy again and again and again. I've known projects which started out in one language because of the ease of prototyping, then switched from language to language as the project's scope expanded.

A good team with good programmers and good discipline and the freedom and flexibility to refactor and revise the design of the project to make the current version sufficiently easy to maintain and modify while allowing future expansion is in a great position to continue to deliver business value.

The technical requirements are a language with libraries and tools of sufficient quality to allow development, maintainability, and deployment.

"Sufficient", of course, is a management weasel word which hides a great deal of complexity and other assumptions—but that complexity and those assumptions depend on your business needs and your available programmers and....

Even so, some of us have a secret weapon. Given an additional resource, such as the ability to manage deployment yourself (without the limitation of, for example, a $3.95/month shared hosting plan, an internal IT system which mandates the use of WebSphere, or the Silicon Valley requirement that all new startups must make use of monkeypatching), sometimes you can find a dramatic improvement in quality or deployability or deliverability or ease of implementation or clarity of code or not having to write much code at all.

For me, that's Perl. That's why I care about improvements to Perl 5. That's why I care about a Perl 6 in which I can write and with which I can deploy great applications.

Perl is my secret weapon.