Practical Questions about Marketing Announcements

Most of my work lately has me developing and supporting a suite of tools for a group of users spread out all over the world, especially Australia, Taiwan, and London. Our goal is to deploy new versions of our software every week, though sometimes (yesterday!) something comes up that requires immediate attention and other times (December!) there's nothing pressing and our usual maintenance and cleanup takes a priority.

Having to ship and support software used by end users—people who wouldn't know what to do with the source code if they had it and who don't care about that anyhow—offers a different perspective from the world of free software, where source code talks and often the best way to figure out how to use a library is to read the code itself. I do that regularly.

Having the success or failure of a business which employs multiple people depend on your ability to deploy and maintain working software offers a valuable perspective, too. (I've never worried about my own future, but the livelihoods of other people weighs more heavily on me and the decisions I make.)

That pressure to ship and maintain working software is valuable. Not only does it help me and my team take the quality of our work and our culture and our software very seriously, but it guides us with an eye to the long term stability and sustainability of our work.

One of my first tasks was to turn a test suite of about 60 assertions, most of which failed, into something usable and useful. In four months, we've grown that test suite by two orders of magnitude and have prevented countless bugs from reaching end users. We've also used the test suite as a guide while refactoring and making more disruptive changes, to demonstrate that cleaning up parts of the internals have no deleterious effects on our users. The combination of the will to make these changes, the time in the schedule to perform them, and a test suite to verify them has improved our code measurably.

One ongoing topic of refactoring is the naming of similar methods within our data access layer. A previous reorganization extracted a distinct layer and moved a lot of code to that area. Unfortunately, it also exposed inconsistencies in how we refer to things. Naming is important within that section of the code because names are a big part of the API. With good names and useful abstractions, you can skim code and understand what it's doing because the names give you semantic hints as to the intent of the code. Inconsistencies make you slow down while reading and really slow down while writing because you have to memorize special cases. (Lest any Lisp fans think I'm praising homoiconicity, I'm not—syntax also helps you skim. That's why we don't write telegrams to each other anymore.)

That naming is hugely important for the maintainability of our product, but it's only relevant to our users insofar as if we fail to provide good software, the business suffers.

That's how I see the "Yeah, we should probably consider doing some marketing sometime" discussion in the Perl community, especially the part which manifests itself as "This version number thing is really a mess, isn't it?" every six to eight months. (Alternately, maybe the Perl community suffers from SAD: Sub-version Affectation Disorder.)

Project management should be a familiar concept to most of the people reading this (many of you write software, right?), but the discussion has spun so bizarre this time it's almost as if project management principles have defenestrated themselves. If I were trying to manage this project, I'd have a lot of questions about a name change:

• What is this trying to address?
• Does it meet the needs of real users?
• If so, who are those users? Have you talked to them?
• When can the users take advantage of the change?
• Who is available to do the work? Are these people willing to do the work?
• What will it cost to do the work?
• What are the opportunity costs of doing the work?
• When will we start seeing the benefits of doing the work?

All of the suggestions I've seen so far to change Perl's naming or numbering scheme fare poorly on this checklist. (One imagines the mental gyrations necessary to argue that adding yet another way to enable a feature set in Perl 5—besides use feature; or use 5.016;—will go over quite well with novices, who just want to get something done, not beg a compiler to help them write decent code.)

To my mind, these proposals make the problem worse, not better.

Remember Ponie? Way back in 2003 (I think), when Perl 6 seemed like it was really taking a while and no one was sure if they'd be able to use their Perl 5 code, or what kind of a future Perl 5 would have if Perl 6 came out before 5.10 or 5.12, at OSCON the Perl 6 developers decided to announce a serious effort to port Perl 5 to run on Parrot, even going as far as to give grant money to work on the code.

The announcement was big and popular. It did get attention, and much of it positive. The admission a few years later that Ponie had gone nowhere was somewhat more subdued. Tomorrow—16 February 2013—is apparently an auspicious anniversary. Tomorrow, the Perl 6 effort is as old as Perl 5 was when Perl 6 was announced.

I can forgive you for suspecting, as I do, that the last thing Perl needs these days is another big announcement without working code to back it up. (I would gripe much less about Perl 6 if any implementation met my goals of "I can use this to build code I want to deploy to paying customers".)

The announcement of Moe was different, because it's clearly labeled as an experiment. If it fails, it doesn't hurt Perl. How could it? It's an experiment. It's okay if it breaks code, because it's an experiment. It's okay if no one uses it, because it's an experiment. The same goes for other flights of fancy and Perl 5 forks, such as Topaz and Kurila. (I haven't decided how "Ponie" fits into this neat little box.)

Once you get past all of the questions about "Is this useful?" and "Will this help real users?" and "Is this really the most valuable thing to do now?" you get to practical questions such as "Who's going to do the work?"

Some readers might remember that I tried to make Perl 5 enable strictures by default in 2009, with something called strictperl. That patch created a new Makefile target which built a binary named strictperl with that simple change.

The patch has two problems. First, it's not necessarily the cleanest way to do things (and it may not even work anymore). That's fixable. The second problem is bigger. Almost none of the core libraries work with it enabled.

To make that patch work for a new shiny Perl fork, with a new version number or codename or whatever, someone or someones will have to go through the core libraries line by line to fix them up in a new world of strictures, or else you won't be able to use the CPAN. At all. (And even then, you'll probably have to patch quite a lot of the CPAN to get modules even to pass their tests, even if all of the work is adding no strict; at the top of all code, at which point... yeah. Some progress.)

Who's going to do that work?

Who's lining up to do that work?

Will all of the volunteers please take a step forward?

(I wish I'd learned this a long time ago, before I said some really stupid stuff to Rafael, for example. Wishing for something awesome doesn't work. Telling other people how awesome it would be if it happened doesn't make it happen. Even rolling up your sleeves and hacking on something for most of a decade doesn't necessarily make it happen, but that's a different story.)

You can change names and numbers and issue press releases and pat yourself on the back for how wonderful this brave new world you've created in your head is, but without people who are actually willing to do the hard work of making that vision usable and useful, you're not going to fool anyone.

I understand the desire to blow off steam, and I understand that people are trying to find real solutions to perceived problems, but it would be nice for people to keep the "practical" part of Perl's preferred backronym in mind.

If that hasn't convinced you, consider that you're trying to solve the problem of "People haven't heard the serious marketing message of the past couple of years that Perl 5 and Perl 6 are separate languages, and Perl 6 isn't going to supplant Perl 5 any time soon if ever" by introducing a new marketing message targeted at people who don't really pay attention to Perl's marketing messages to not pay attention to. I get even less enthusiastic about its chances of success when I consider that the point of the proposed marketing message depends on the recipients understanding several nuanced points about it. Remember, the apparent target audience for this message are people who see the name "Perl" and think that "5" or "6" is a version number. You want a two-by-four, not nuance.