When it comes to writing software – regardless of the type – it seems as if it’s always easy to get the first 80% done. This isn’t a new problem, either. You may have also heard it stated as:

80% of the work is done 80% of the time.

Or some variation thereof.

But anyway, when it comes to a project like WordPress – which is software – and it comes to projects being built on top of it – which are also software – then it stands to reason that they are subject to falling into the same trap.

And they are.

This is why this particular aspect of the philosophy is so important.

The WordPress Philosophy

Of course, for anyone who has followed not only WordPress but who have worked on projects that sit on top of it as a foundation, then you know that deadlines have slipped and work that we do does miss deadlines.

There are so many different reasons that people can list for this that an entire series of posts could be written about each one in and of itself. That doesn’t mean that this part of the philosophy is being ignored, nor that we should treat it lightly.

If anything, I think it builds a stronger case for why it’s needed.

The WordPress Philosophy: Deadlines Are Not Arbitrary

Specifically, the philosophy says:

Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release. We aspire to release three major versions a year because through trial and error we’ve found that to be a good balance between getting cool stuff in each release and not so much that we end up breaking more than we add.

Good deadlines almost always make you trim something from a release. This is not a bad thing, it’s what they’re supposed to do.

The route of delaying a release for that one-more-feature is, literally, a rabbit hole. We did that for over a year once, and it wasn’t pleasant for anybody.

The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.

As I’ve mentioned earlier, as someone who has been involved with WordPress for several years, or if you’re someone who has been using WordPress for any significant amount of time, then you’re likely aware of times when deadlines on the core software have slipped.

But that’s not what this post nor the entire series is about.

Instead, it’s about applying the philosophy in our own work – in our themes, our plugins, and so on. And just as the core application has its hits and misses with deadlines, as does are our work (we’re kidding ourselves to say it doesn’t).

What we should want to do is pick a date for release, aim for that date, and make sure that we do everything we can given the requirements and the scope to hit that deadline.

What Am I Getting At?

But that’s a hard thing to do, isn’t it? I mean, how many projects have you worked on that have had a list of requirements that seemed realistic at first but were almost always subjected to something coming up that was unanticipated ultimately delaying the release?

If you can’t think of any, then you work somewhere amazing, you’re amazing, your projects haven’t been large enough, or you’re a liar :).

But in all seriousness, projects rarely go the way we expect from the outset. There are reasons for this, too:

  • Solving a problem took longer than expected,
  • Requirements changed after development had started,
  • Scope creep,
  • A given task had more dependencies than originally planned,
  • …and so on.

That doesn’t mean that there aren’t things that we can do to mitigate this from happening. And yes, there are a lot of strategies that are available for building software – Waterfall, Scrum, various Agile methodologies, Spiral, RAD, and on and on the list goes.

That’s not what this is about.

This is about taking a pillar that’s a core part of the philosophy of WordPress and applying it to our day-to-day work.

So What Should We Do?

For starters:

Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release.

This is an excellent starting point: It recognizes the problem that all software faces (that is, cramming in a lot of features), and proposes a solution (which is setting a deadline even at the expense of some features).

As far as WordPress is concerned, I think that they do a pretty good job of this (remember the post formats overhaul?). Anyway, when it comes to building our own work, I’ve talked numerous times about creating a “strong 1.0.”

Generally, this consists of a core set of features that serve as the very foundation on which future iterations can build, improve, and add to the core project. Ideally, these are the features that are nothing more than the must-haves in order to ship a product.

Identifying these varies from project to project so I can’t offer any prescriptive advice on this, but I do firmly believe that a 1.0 should be lean, focused, and should achieve nothing more than the core vision of the project.

Good deadlines almost always make you trim something from a release. This is not a bad thing, it’s what they’re supposed to do.

This is something that I think anyone who develops software should remember, because I believe that we’ve got it backwards: Rather than saying “hey, let’s move this feature to a future release,” we end up saying “let’s kick the release date back in order to accommodate this feature.”

The route of delaying a release for that one-more-feature is, literally, a rabbit hole. We did that for over a year once, and it wasn’t pleasant for anybody.

When you take a step back and look at the bigger picture, it’s hard to imagine why we’d want to do this: Software should have a roadmap, shouldn’t it? I mean, don’t we want to have longevity in our work? Don’t we want to be able to release things as the product matures?

To that end, why try to cram it all in the first version?

The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one.

I think that it’s a great idea to set our customer’s expectations. If they were to know that we’d be shipping something on the same day of every month, every quarter, or whatever, and there was some public record that provided a means why which this could be done, it’d be exciting for all parties involved, wouldn’t it?

It builds anticipation for the pipeline, it gives us the ability to focus on a core set of functionality, and it continues to allow our project to mature.

But we’re so programmed (pun partially intended :) to try to shove everything into a “big bang release,” that we not only risk a roadmap for our product, but we also potentially exhaust ourselves trying to get it out the door, and we may even be introducing more bugs than necessary all because we’ve opted to try to create the biggest and best early on.

Ultimately, I think it’s about refocusing our efforts on the core product and doing what we can to more strictly identify the nice-to-haves and the must-haves.

From there, we work solely on the must-haves and build that foundation. We test it, we iterate on it to shake out any bugs, and then we get it into our customers hands. From there, we listen to the feedback: They will find bugs and they will have suggestions.

Vetting whether or not the suggestions should be built into the core product or perhaps as an extension is an entirely different subject matter, but it does help us to determine a roadmap that helps to give our products a lifetime.

We’re all well aware of the problems that come with themes that try to be the end-all-be-all with their “powerful control panels” and their “n-number of options” and I’m not about to regurgitate the same stuff that others have because we already know what this looks like.

But imagine what it would be like to receive a theme that had only a handful of options – or notoptions at all. The customer is to simply activate the theme and it just works. There are no knobs to twist, there are no buttons to press. What they see is what they get – no tweaking required.

Then, over time, we slowly introduce new features and ease ourselves as well as our customers into the new functionality.

Doesn’t that sound much more appealing and much more realistic that the mess that we’ve created right now?