Developing WordPress for the Enterprise

An Inside Look at Enterprise Organizations

Now before I talk more about WordPress, let’s look for a second inside an enterprise organization. I work for a company that develops enterprise software (some of it desktop software, some of it hosted SaaS). In one of our vertical markets, we have over 50% market share – so we’re not playing at this game. We’re in it to win it.

I say that because I’m not talking about frustrations from a frustrating place. We’re in a good spot. But in that particular market, we sell our software to cities and counties – where they have hundreds, if not thousands of employees.

Rapid Development Iterations

When I joined the company just over seven years ago, I was shocked to hear we were delivering monthly releases. But it was a pendulum swing from when it had taken us too long to get releases out the door. There were a lot of reasons for what was going on, but let me highlight one particular aspect.

We had separated features from releases.

Now, I know, you’re wondering what that means. The idea of a release simply became a bundled set of software we delivered on a specific date. The best way to ensure that date was to only deliver whatever features were ready at that moment – at the time we’d release.

The net effect of this approach was that we’d be able to determine, right before the test or release build, if a feature was ready to be included in the build. Sounds great right? It’s like saying,

“We’ll release no wine until it’s time.”

The benefits go beyond releasing only software that’s really ready. It also allows you to set specific dates. Because you push out whatever is ready for that release. So the date is never missed. What changes is what’s in the release.

The Challenges of Fast Iterations in the Enterprise Sector

And this is where you start seeing the wheels fall off, on so many different levels.

First, it made it a lot easier to do releases. So we did them. First it was quarterly and then it became monthly. Because it was so easy – and because there was always someone who wanted something tucked in right at that moment. Perfect! Stick it in the monthly release.

Second, it made it feel (and this was even happening with quarterly releases) like certain releases weren’t applicable or required. See if you only end up releasing the stuff that’s ready, and the stuff that’s ready doesn’t relate to a customer, then they decide to skip it. In and of itself, that’s a bad consequence. But there are three ancillary problems that arise, which I’ll hit next.

Third, because some clients skipped releases (“oh, that’s an internal engine release, I don’t need that”), the spread of customers on product versions shot thru the roof.

When I joined, we had customers on a spread of releases that was 6 or 7 versions wide (1.x), with even greater variance across dot releases (1.x.y).

Fourth, supporting customers across such a spread was ridiculously difficult. This is software, after all, so there needs to be environments and people have to develop experience on whatever release they’re supporting. So you either specialize (creating spare cycles of bandwidth when no version-specific tickets are coming in for that person), or you have everyone support everything and things slow way down.

Fifth, when clients are skipping releases, their requests for custom software get more complicated because they’re asking for things on various versions of the software – including older versions that don’t have what you need it to (infrastructure).

The Consequences for Add-ons/Plugins

You can imagine, from the experience I’m describing above, and with the final issue articulated above, that custom development (where we create an add-on for a customer, and then release it to other customers) was a serious burden.

This had nothing to do with the fact that we’d unhinged features from release dates. This had to do with the consequence of that fact.

Because the consequence was a greater spread of versions we had to support – as clients opted to not stay on the very latest release. And that wasn’t just because of the unlinking of features to releases, but also the rapid release cycle.

Even when we moved to quarterly releases, corporate change every three months was seen as “too fast” for many of our clients.

So the results were the same – greater client/version spread.

And with that came our largest development challenge. Because when you have clients spread across so many versions, creating add-ons (which in the WordPress world would be plugins) can be prohibitively expensive.

• Do you only build features for the latest version?
• Do you build it for whatever version the client is on, because they’re going to pay?
• Do you build the mother of all add-ons that can work on a 12-version spread?
• Or do you look for ways to get everyone back on the same release version?

It’s not that tough, look at Chrome & Firefox

By this point, you’re likely thinking that it was just our organization that was hosed. After all, other companies have figured out how to roll out small patches without us even knowing it, right?

You might be thinking I’m talking about Microsoft and their auto-updates, but you’d be wrong, because years of working in the Microsoft server world has taught me better.

Microsoft updates have single-handedly taken servers down and created uptime issues for hosting servers. So clearly I can’t use them as seamless examples of updates that don’t impact users except for positively.

No, the example that we’ve heard talked about is actually Chrome and/or Firefox – web browsers. The idea is that you can keep people updated without them having to stress about it at all.

So let me ask you a simple question – particularly if you have enterprise experience.

When was the last time that happened to a piece of business software (not a browser)?

When was the last time someone updated their company’s accounting software, Microsoft Office, or operating system without any stress?

And this is why the idea that auto-updates will protect the user and keep them updated, like an experience with Chrome is false. Employees that use browsers typically do one thing with them – visit a site. The experience is simple and straightforward: type in a URL (or search term) and hit enter.

Now watch people use Office. They do different things with it. The software isn’t simple. And changing it, in any way at all, worries IT departments.

So guess what? They create implementation projects. They sometimes hire staff to manage what can easily become a multi-year project. All just to upgrade mission-critical software.

We can say they should get used to it. But they’ll look at us and smile. They’re the multi-million dollar companies that don’t play lightly with risk. A single question will stop us from making our argument.

Can you assure me that this next auto-update won’t impact a single plugin’s functionality?

And with that, we get stopped and assigned to the multi-year project plan to upgrade software.

Wait – there’s more: Retraining!

Before you presume I’ve made the case for why I’m worried about how enterprises will react to the most recent WordPress development strategies, let me hit on one I already did this morning on the WPwatercooler show – the cost of retraining.

Let’s first assume the best-case scenario:

• You’re able to fully articulate exactly what’s going into each release
• You’re able to assure customers that every release is important
• You’re then able to get them to agree to update
• You’ve eliminated spread and everyone is on the latest
• You’re able to provide excellent support because of it

Ok? You’ve read all of the above and figured out how to move past it. Perfect.

So now you move into the argument I was putting forth this morning, which my friend Jason responded to today in a post.

To fully appreciate it, and to lean on experiences you’ve already had, let’s look again at how people use Microsoft Office.

They create eBooks in PowerPoint. They create tables in Excel. They create agendas, books, research, and letters in Word. And every one of those interactions causes them to touch a different part of the system.

So what happens when you change a part of the system (especially via an auto-update)? Ask around about Microsoft’s “new” ribbon interface. People are still using a version from 2007 in order to get away from change. Or check out how many people are rocking Windows 8? You know the one with the brand new interface.

The problem is one of change – but not just because of all the issues we already looked at. It’s not about fear of change. It’s not about IT planning.

No, in this case, it’s about the cost of retraining.

When you change one thing – one little thing – in an organization of hundreds or thousands, plan on seeing the ripple of that change taking place over years, not weeks or months.

I know this personally.

We wanted to introduce a new navigation bar. That’s it, just a new shortcut menu, at the top of their screen. We left the old menu in place (just called it “classic” and hid it by default).

But before we did it, we did months of demonstrations. When I write months, don’t think 1 or 2 or 3. Think 12 or 14 or 16. And then we made the change. And guess what?

Some customers freaked. Because we made the mistake of training IT departments and did demos for decision-makers. Not end users.

And it was end users that freaked.

Any change at all, and I mean any, can cost an enterprise organization months or years of time in training/retraining. To roll out that little menu took us almost three years (no exaggeration).

Developing WordPress for the Enterprise

If you watch the State of WordPress, the entire logic of the argument sounds wonderful. I know because I’ve seen, heard, and lived it. I thought it was driven by a natural consequence of a release (like 3.6) taking so long, but Nacin assures me it’s not. It’s just that the current approach is too long, according to him.

Additionally, the folks behind the strategy aren’t dumb. They’re looking for ways to accelerate development while mitigating risks – in this case the risks they’re familiar with.

In fact, the driver isn’t separating features from releases, but rather feature development from release schedules – which is a nuance that I hadn’t caught. Will the result be a better approach to the enterprise sector, or will we see the same consequences I’ve seen in the past? I don’t know.

My only assertion is that the approach and message, if not managed, will not work well in an organization that has revenues in the billions instead of millions. In fact, I’ve seen these challenges in companies with only 100 million in revenue but tons of content-producing/application-using staff.

But does it mean that WordPress won’t be able to go into the enterprise space? I don’t think it means that. Does it mean we need to fork the product to do that? I don’t think that either.

Instead, I would make three suggestions to the approach.

Shift from 3 to 4-month cycles

I ‘m making this statement based on the expressed articulation of an October and December upcoming set of releases. That suggests quarterly. And moving to less than quarterly is a good thing. This doesn’t completely reduce the stress to IT organizations, but it drops one of the releases. And that helps.