There are three things that I really love about Perl:

Moose

Catalyst

DBIx-Class

That's where the problem starts. It's not really a BBC problem, though. It's a problem for all "enterprise" customers.

I just tried to upgrade Moose and got the following message:

*** This version of Moose conflicts with the version of Catalyst (5.80007) you have installed. You will need to upgrade Catalyst after installing this version of Moose. *** *** This version of Moose conflicts with the version of MooseX::AttributeHelpers (0.2) you have installed. You will need to upgrade MooseX::AttributeHelpers after installing this version of Moose. *** *** This version of Moose conflicts with the version of MooseX::MethodAttributes (0.14) you have installed. You will need to upgrade MooseX::MethodAttributes after installing this version of Moose. *** *** This version of Moose conflicts with the version of MooseX::Types (0.16) you have installed. You will need to upgrade MooseX::Types after installing this version of Moose. ***

I'm doing this for a personal project, Veure, but when I see message like that, there's an issue. Specifically, enterprise customers.

The Perl community is largely a community of JFDI hackers (thanks, Jesse!). However, corporate users have a different issue. We have admins. Lots of them. We have projects. Lots of them. We have boxes. Lots of them. We have operating systems. Lots of them. We have versions of Perl. Lots of them. We have databases. Lots of them. We have modules installed. Lots of them. We have tests. Some of them.

Now take those "lots" and start doing some imaginary math. We have very, very busy admins. As a result, we have to submit a reason for every change request. On a personal project, I'm quite happy to upgrade this code because there's no chance I'm going to impact others. In a corporate environment, things start to become more tricky. Admins would like to see this:

One operating system

One programming language

One version of said programming language

One database

One standard set of modules

One box (hah!)

... and so on

I know that some people dismiss this with comments like "your admins must not be very good" or something like that, but small systems turn into large systems which turn into huge systems. Along the way, admins leave, new admins start. They leave. More admins start. Critical business knowledge is lost and rediscovered. Business needs change. Systems evolve in ways that the previous architecture doesn't support.

The BBC is not a small company and frankly, I've loved the quality of people that I work with. These aren't idiots, but they are busy and requirement management is often akin to skeet shooting while blindfolded. Even that isn't as silly as it sounds because sometimes the law changes and we must rapidly adopt to it. Now that London is hosting the 2012 Olympics with its Bart-Simpson receiving a censored logo, we have to address this. Other TV stations may change direction and decide to work with the BBC or against the BBC. We don't know their decisions in advance and this again causes us to rethink what we do. Heck, I could (but can't, sorry), tell you fascinating stories about challenges we constantly face with iPlayer (Americans: think of it as the British Hulu) which force us to rethink technology solutions all the time.

In other words, what we do is hard. Very hard. People who don't work here have no idea the technical challenges we face.

Recently I proposed fixing an issue in our code base where package and filenames didn't match. As a result, multiple filenames contained the same package. This was apparently a bug workaround, but now it's a time bomb. Fixing the issue was denied. Why? It's not a problem yet, but getting new features out the door is a problem.

It's not just obstinate management. Part of the issue involves possibly upgrading to a new version of Catalyst. However, we can't just tell the admins "upgrade this". We have to tell them "upgrade this and here's why". That's because they're busy and if every one of our many, many teams was upgrading everything all the time, without having a concrete business case, fewer features would get out the door. Thus, I wanted to fix a potential bug (one which modern versions of these modules sensibly warn about), but I couldn't demonstrate that it was actually causing a problem. Thus, my business case was weakened vis-a-vis the fact that we're preparing for the Olympics.

Olympics versus "not a bug". I report. You decide.

I'm not taking a stand one way or the other. It's very, very important that these projects address issues they have and appeal to developers who want these issues addressed. However, as I've encountered time and time again in large environments, upgrading is problematic. As a result, we tend not to upgrade until we need a particular feature and can make a business case for it. Thus, for the best projects with the most active developers, individually we love it (I certainly do), but at a corporate level, it becomes a sysadmin nightmare. That's because we tend not to upgrade unless we absolutely have to but our software is so out of date that we're practically shutting down our work to upgrade everything we need, including rewriting large parts of our software to match. Meanwhile, we have to make sure that our publication latency is reduced as much as we can when journalists covering the Olympics or World Cup want to report something live.

I've successfully upgraded "not a bug" modules on the grounds that we need to ensure that when we must upgrade, we're not so far behind the curve that the upgrade is very difficult. I've not done this often, though. Our Catalyst is a year old (I think) and we've no plans to upgrade it because it's "not a bug".

There is a terribly tension between those who need stability and those who need new features. I don't have the right answer here, but the problem is not as simple as some would suggest.