One of the phrases many involved in software will likely hear (especially early in their career) is “Ship fast and iterate.”
And there’s definitely something to that when it’s been implemented correctly. But when I’ve watched others trying to adopt this idea when building something for WordPress, it seems like something gets lost in translation.
No, this is not a critique of other companies or developers. No, this is not saying that we’re all like this. No, this is not saying that I’m above this.
If anything, it’s a reflection on the idea and what it means for those of us who are building things on WordPress and how we may be more more mindful of the work that we’re doing.
Ship Fast and Iterate (Or What?)
When doing some initial research on this particular phrase, I found several variations of it. The first time I heard it was some time back in college, but I think the latest version of the quote may be from Reid Hoffman (of LinkedIn):
If you are not embarrassed by the first version of your product, you’ve launched too late.
This sounds like such good advice because it means we, as developers, can fall back on some excuse for why the first version of our product disappoints our customers.
Oh, you know, we needed to get the MVP out ASAP to gauge market interest and other synergistic attributes.
I know, snark, snark, snark. But what’s a post without a little fun?
My First Job
During my first job out of school, I worked for a Top 40 Internet Company. There was a sizable engineering department.
- We at very high unit test coverage
- We performed hourly builds
- If the build broke, we were notified immediately.
- We performed daily deployments.
- If the build was broken at 4pm each day, the deployment was not made.
Clearly, we were shipping fast and we were iterating quickly on our projects. But was the quality sacrificed? Nope. Because if a feature wasn’t ready but the code was deployed, it wasn’t accessible (through various control measures we had in place).
What’s The Moral of The Story?
The point I’m trying to make is that if a site with a global presence can perform daily builds, then those of us working building things for much a smaller audience should be able to pull the same thing off.
And many do and do it well. But we need to remember “ship fast and iterate” does not translate to “get something out there even if it’s broken.”
No. This means that you’re trying to get something out the door while sacrificing quality. Why would we do that? What do we have to gain from doing something like that?
The idea is not to be used as a crutch or an excuse for weak software, poor performance, the presence of bugs, and so on.
What Does It Mean?
Personally, I’ve always interpreted it as the idea we create a “Strong 1.0.” That is, we build in the essential features that are critical to solving a problem, but we don’t throw in things that may not necessarily be core to the solution set.
This doesn’t mean we’re saying “no” to said features. It means we’re saying “not right now.”
Furthermore, having a strong, working product in the hands of users also opens the doors for feedback. This means we are able to hear from those who are looking for a solution to the problem that we’re trying to solve. They will let us know if we’re on the right track or not.
Don’t Release Weak Products?
That’s the gist of the post. If I cared about writing a TL;DR, then I would’ve done so at the beginning of the post.
The thing is, this idea of shipping fast and iterating has proliferated throughout the software development community so much – at least the open source community – that I can’t help but wonder if it’s lost it’s meaning and has becoming nothing more than an excuse we give to people when something we’ve built doesn’t work.
Whatever the case, this is nothing more than a personal reminder (that I’ve obviously decided to make public) that we need to make sure that whatever we usher out the door first is shipped as quickly as possible without sacrificing the quality it, and our users and customers, deserve.