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?