Software, Development, and WordPress

Maybe Worse is Better

I recently read an interesting article about the concept that Worse is Better.

It’s a long article with a few outbound links that tell the story of a guy working with Lisp, AI technologies, and how his opinion ended up generating a lot of feedback so much so that he ended up writing rebuttals to his own work.

Funny, right?

But I couldn’t help but think about how we – as developers – would go back and do the same thing. It’s the whole “if i knew now what I knew then” situation.

This post is not about that article, per se, but there’s a quite at the beginning of the article that really struck a chord with me:

The concept known as “worse is better” holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. Christopher Alexander might call this “piecemeal growth.”

You can read the article in its entirety, but I wanted to share some of the conflicting thoughts that I’ve had on this topic – at least on the quote above – as it relates not only to WordPress development, but to software development in general.

An Issue of Transcendence

First, I think it’s important to define that writing software for WordPress (or even contributing to WordPress) is software development, therefore the concepts that apply at this particular level often transcend the platform on which we’re working.

Or, more simply stated, the principles that we apply to WordPress are often applicable to Rails, .NET, Python, and any other framework or language that’s available.

So with that said, note that the topics at hand aren’t isolated to WordPress alone.

Ship It Now

One of the more common ideas that we hear is how important it is to ship. I credit Seth Godin with this particular idea. He summarizes is in that we all have a fear of shipping, but if we’re going to ultimately do it, why prolong it?


Since you’re going to ship anyway, then, the question is: why bother indulging your fear?

There have been times where he relegates shipping to anything from writing a blog post to releasing an application. There’s a huge gap there, sure, as the time it takes to “bring an article to market” is much shorter than the amount of time that takes to bring a product to market.

But the level of fear may be the exact same depending on the author(s).

As a developer, I have somewhat of a fear of shipping not so much because I fear criticism – after all, that’s a given and you eventually just get used to it – but a fear of, say, missing some critical component that may impact the end user’s experience.

So at what point is worse better? Do we ship with what we’ve got knowing there are defects that we missed and allow our users to discover them, or do we delay shipping slightly longer in order to perform more testing?

Draft The MVP

Every entrepreneur and his mother tosses the word “MVP” around, but I don’t know how many people are good at truly identifying an MVP.

In fact, I don’t know how good I really am at identifying an MVP. I can define it, but I don’t know if I can identify it. That said, I do know that I’m relatively good at identifying a 1.0 and identifying must-haves and nice-to-haves.

If you define an MVP as a strong 1.0 with nothing more than must-haves, then I’m good. But when everyone is talking about creating, prototyping, and/or shipping an MVP, is the term being diluted to the point an MVP is what? A 1.0? A base product?

What becomes the new MVP?

Iterate Quickly

Any quick Google Search will go to show just how much this topic is discussed. The thing is, I’m a fan – but how do you measure quickness?

I don’t think it’s as simple as quickly turning out a new release as fast as possible.

I see it as a function of the following:

  • Resolving a number of known bugs
  • Introducing a new feature or set of features
  • Refining existing features, and then releasing.

This is different for every developer or every team, so “quickly” becomes relevant.

So what’s worse? Attempting to constantly push out updates or setting a cadence – such as quarterly releases – in which you’re creating a predictable schedule of improvements, or turning around quick changes asking users to upgrade shortly after they’ve just updated to the last good update?

I Don’t Know if Worse is Better

If you read the article that I linked at the beginning, you’ll quickly note that this particular post is a deviation from his topic at hand, but the initial quote stuck with me for the last few days so I thought it worth sharing and discussing here on the site.

All that say, I don’t know if worse is better.

If worse is a by product of mistakes from which we can learn, then ship away; otherwise, don’t use it as a crutch to say you’re releasing products.


  1. John Saddington

    f’in ship!

  2. Saru Tole (@SaruTole)

    Tom, thanks for the topic. I am 100% for “strong 1.0”. There are many cases when Lean Startup philosophy works, but there are situations when it does not. But I want to delibarate more over that “Worse is better” thing. It is similar to “Less is more”, but they are not exactly the same.

    To my understanding, “Less is more” is about “simplicity as the ultimate sophistication”. This phrase has some “poetic” qualities. Whereas “Worse is better” means you just refuse to worry about feature parity, and you do not try to be all-things for everyone. This phrase is more about “the prose” of bringing a new product to the market.

    Let me elaborate.

    Taken for its face value, “Worse is better” might be a catchy phrase, but it is not very meaningful. There were times, when the “goodness” of software was decided based on the length of feature list, and it was mostly about enterprise software systems. At that time, this statement was very thought-provoking, and no wonder many smart people took interest in that paper/talk.

    For the first two decades of personal computing, the trend was similar — “better” was equal “more”. Every new version of Office had more features, ergo, was better. Only with the rise of web apps it started to change. But *mobile* computing, starting with iPhone apps, turned the tide completely. “Less is more” became a new mantra of a large part of the Software industry.

    So much so, that in the late hour of App Store gold rush, Apple had to declare:

    “We don’t need any more Fart apps. If your app doesn’t do something useful or provide some form of lasting entertainment, it may not be accepted.”

    To bring the discussion home, I will dare to state, that there are plenty of WP plugins and themes that are much worse than iPhone fart apps. Why worse? Because they frustrate users, they leave them vulnerable security-wise, they require many customizations, they slow down or completely break websites.

    And these are not necessarily plugins/themes written by beginners and/or nonames. Some of them have brand names, book authors, community leaders behind them.

    It’s ok for a new plugin/theme to have a bug or two. But it’s not okay, when a product is faulty by design.

    Worse is not better, when a theme/plugin can be described as a marketing ploy to attract interest for a premium version of the thing.

    Worse is not better, when a theme/plugin is positioned as “premium”, “commercial”, “pro”, “business”, but in fact it’s just a shaky proof-of-concept, at best.

    Worse is not better, when a theme/plugin is marketed as a “niche theme”, a “turn-key” solution, but what you get is just a generic cookie-cutter, which kind-of works, but is not particularly good at anything, and you have to spend countless hours further tweeking and hacking it.

    (The list is far from exhaustive, you are welcome to add to it.)

    To sum it up, “less is more” should not become a euphemism for rough and unfinished, and “Worse is better” should be left for sophists and IT historians. ;)

    On a more practical note, we should best avoid promoting vapid and incomplete products (even those that are “free”), as they reflect poorly on WP as a platform and on us, as WP developers and WP product people.

    Thanks for reading!

    • Tom McFarlin

      I think this comment is fantastic. You and I are very much in sync on a lot of issues here.

      I am 100% for “strong 1.0”.

      As am I – so much so that I can actually aggravate myself (and my team, when working in that environment) on whether or not something should be part of a 1.0 or not.

      “Less is more” is about “simplicity as the ultimate sophistication”.

      Certainly, but I think that this particular phrase has been hijacked as an excuse by people who don’t necessary get it.

      I see designs that aren’t actually designs at all and people are claiming that it’s less. I see software that barely does anything – or does something half-baked – and they claim it’s because less is more.

      But that’s not right.

      You can have a strong, feature rich application and it still employ the “less is more” philosophy.

      That’s where the poetic nature comes into play. It’s about making the components of your application work well together. Not skimping on things that are true valuable, usable features.

      Because they frustrate users, they leave them vulnerable security-wise, they require many customizations, they slow down or completely break websites.

      Straight up in complete agreement here. This is yet another reason that I’m slowly beginning to work on moving things away from the repository.

      The vetting process is getting much better and developers that I greatly respect are now the gate keepers of the repository.

      WordPress is an easy (and enjoyable) platform on which to develop, but the barrier for entry is low so there are certainly some dangers in using tools from the newer developers.

  3. Saru Tole (@SaruTole)

    Thanks for response, Tom. My comment above migh have come off as a bit rough. Sorry ’bout that.

    Low barrier for entry is one of the reasons WP is so popular. On the other hand, if not all those half-baked themes and plugins of yesteryear, there would have been no need for us — WP consultants, themers, coders… and other kinds of website-saviors! :)

    • Tom McFarlin

      My comment above migh have come off as a bit rough. Sorry ’bout that.

      I didn’t read it as such. It seemed thoughtful and well-reasoned, so I enjoyed reading it.

      There would have been no need for us — WP consultants, themers, coders… and other kinds of website-saviors!

      There is truth here, though I’d much rather be known as someone who builds quality products on WordPress rather than someone who saves others from sinking in the mire of bad code they inherited ;).

  4. Saru Tole (@SaruTole)

    Wow, this is timely illustration of when “worse is better”:

    “Enterprise software sucks. The message has become, “less expensive means easy to use, more expensive means really difficult to use. We have to remedy that!”
    ~ Carl Bass, Autodesk CEO, source: ReadWriteWeb

    Just like I said, this statement makes most sense when it comes from a maker of unwieldy enterprise software. :)

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑