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.


speaking of Perl 6. does it have a CPAN yet? what are they doing to make sure they don't repeat the mistakes of the p5 CPAN?

@xenoterracide I don't know if that question could be answered. Define the mistakes of the P5 CPAN.

We don't really have a CPAN yet, we have a module list at

And I'd be most interested in hearing what the problems of the Perl 5 ecosystem are, and how we should avoid them. People talk about such problems in very general terms, but it's really hard to get concrete, informed opinions on it.

Feel free to join us in #perl6 on and tell us more about it.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide



About this Entry

This page contains a single entry by chromatic published on February 24, 2011 9:33 AM.

Unifying the Two Worlds of Perl 5 was the previous entry in this blog.

Rock Paper Scissors Butterfly Velociraptor is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?