I’ve talked before about my idea of shipping a “strong 1.0” when it comes to working on projects for yourself or other people but what if that version is an embarrassing first release?

There’s a quote that many of us are familiar with (and that I’ve referenced here before, too):

If you are not embarrassed by the first version of your product, then you’ve launched too late.

It’s attributed to Reid Hoffman, the founder of LinkedIn.

I think it’s something that’s good to remember, but sometimes I wonder if we use it as a crutch when shipping something and as a rationalization to cut corners.

That Embarrassing First Release

I know, the introduction to all of this carries a bit of cynicism with it. Frankly, it comes off as if I’m assuming the worst (which isn’t something I intended to do).

Instead, I’m just trying to ask a question that causes us to look at the codebase of projects that we’re shipping for others to use.

A Well-Organized WordPress Theme

Say, for example, you’re working on a WordPress theme, and you know all of the best practices to follow. You know how to use tags, how to add proper features into functions.php to support your theme. You’re even comfortable with using certain hooks to handle more advanced functionality.

All of that’s great, right? But let’s say that you’re a little bit more experienced, and you’re familiar with the WordPress Coding Standards, and you’re familiar with using the PHP CodeSniffer to make sure that your code is up to par.

Furthermore, you’re using tools like Log Deprecated Notices and Query Monitor to make sure that you’re not using anything that’s out of date nor anything that’s going to hurt the performance of the theme.

Once you’re done, you package it up with the proper tags, the proper README file, screenshots assets, and so on, and you have a solid product ready to ship.

The First Release of a WordPress Theme

In short, this is a solid example of how a theme might be structured for its first release. It follows best practices; it conforms to a proper set of rules, and it doesn’t use any deprecated code.

I Have No Idea What I’m Doing

On the other hand, let’s say you’re working on a plugin, and you’re building it using object-oriented programming.

Object-Oriented Programming in WordPress

As above, you’re familiar with the WordPress Coding Standards, the rules you can use with the PHP CodeSniffer, and you’re familiar with best practices as it relates to organizing your classes.

But let’s say that you’re under a tight deadline to ship the plugin. You have a decent organization of your classes, but you know that there are still ways in which the codebase could be improved.

If anyone looks at this code, they are going to think that I have no idea how to really work with object-oriented concepts.

And that’s where I think the real tension comes into play. We know that we can do better as it relates to organizing our codebase, but external constraints dictate just how far we can take the organization for the first version of our work.

So as potentially painful, or embarrassing, as it is, we still need to have the first version shipped especially if there are other stakeholders.

And remember, the nice thing is that it’s software. It’s open to iteration and future improvement and next versions.

Future Releases

So as you ship something that might be a less than stellar version of what you’d like to ship, don’t forget that it’s not something that’s final. It’s something you can revisit, refine, and ultimately reach the level of quality that you’d like.

Besides, as you continue to grow the product, you’re likely to face this same tension again. So that’s something to look forward to experiencing over and over again, right?


Join the conversation! 3 Comments

  1. Hey Tom,

    This is something we all are constantly struggling with, as our own ambitions & expectations often clash against business constraints.

    I personally don’t like the quote above, though, as I think that there’s nothing embarrassing in having a limited scope for the first release. The need for these limitations can be documented, and you can include TODOs within the code or in an issue tracker to keep yourself accountable.

    However, what is embarrassing is to keep the (impossible within deadline) scope and lower the quality of the release instead. You’re setting yourself up for maintenance & support nightmares, as well as starting out with a possibly technical debt right from the get-go.

    So, for your first release, drop optional features to meet the deadline, not quality requirements.

    • Hey Alain,

      I agree with what you’ve said. I think you might have said it far more elegantly than I have.

      As far as the quote above, I’ve personally got mixed feelings about. I think some do try to use it as a crutch (“Ah, I know it sucks but I gotta get this out the door – even the big players have done it!”).

      But I don’t think that’s how it’s meant.

      For me, it’s more about “I’ve got this thing shipped and it working and I see all of these places I want to optimize and improve but I’ve run out of time.”

      So I’m embarrassed in the sense in that it’s not up to what I feel I’m capable of doing, but what I wasn’t capable of doing for 1.0.

      However, what is embarrassing is to keep the (impossible within deadline) scope and lower the quality of the release instead. You’re setting yourself up for maintenance & support nightmares, as well as starting out with a possibly technical debt right from the get-go.

      This! This is what we’ve got to communicate to clients and stakeholders when we’re providing a service to them. Luckily, most of the people I’ve worked with get it so I’m really glad for that.

      But I know that’s not the case for everyone.

  2. I may not agree with the sentiment (without context) of the initial release as “not embarrassing” == “released too late”; but, if the author(s) keeps to a simplified/limited feature set that can be accomplished well then there is no reason to be embarrassed by that initial release.

    As has been suggested, just plan for future iterations that improve upon and/or enhance the features already present in the “1.0” release. I would suggest letting users and/or the target-market know what additional features are planned.

    Perhaps open up lines of communications that can provide feedback and possible influence over these planned features such as issue trackers, public roadmap(s), etc.

    Documentation, inline and external, is also a great way to avoid embarrassing releases and possibly more so is direct communication with the end-users. Expectations may be much different than functionality and documentation can help to explain those differences.

    Basically, no matter what your initial release is, make sure the features that are included are well documented so the user has the opportunity to understand what they are getting rather than expecting something they may not ever see.

Leave a Reply