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.

Tags:

2 Comments

For kicks, I revived the strictperl patch and put it in a branch of blead along with enough fixes to at least complete "make strictperl". Getting to "test_prep" will be another bit of slog. All told, however, it wasn't really that much work.

Note to readers: I'm not advocating this as a default anytime soon. For the moment, I just want to use it as a tool to explore what in the Perl core isn't strict-friendly, so that sometime in the future, that decision is at least an option.

Excellent post outlining what are the prerequisites for such a proposal to be viable.

I believe that the 'Pumpkin Perl' proposal meets every requirement you've given (with the possible exception of "why aren't you using a bigger cluebat", though "because I think I can get permission to wield this one" is the answer to that, as to most "why not name X?" questions).