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?
Specifically:
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.
Leave a Reply
You must be logged in to post a comment.