Early code should be thrashy

Ever wondered why we call it software?

It was a term to distinguish the easy to change parts of the computer systems from the hard to change ones, the hardwares. This still holds some truth, despite the advances in fast prototyping of hardware components, software is unbeatable in speed of changing.

Or it should have been.

Then we made it hard to change. Imposed rules, architectures, protocols and committees to slow down code change, intentionally. To avoid all the mistakes we experienced in the past.

The embarassing bugs. The failed Friday Night Release Parties. The loss of customer data. The terrible rollbacks losing a weekend worth of webshop orders. And worse.

We started to work like each and every website page was a mini nuclear reactor. Where the simples mistake leads to a huge, irreversible loss.

In the process of seeking perfection, we lost sight of the cost of such perfection.

There are critical systems that have to be protected from any kind of mistake. Where a mathematical proof of “it will 100% work” is necessary. Your online course landing page is not such a system.

There are critical systems that have to perform well under scale or your organization goes under. You need to protect the stability and performance of transactional systems so money is safe. A product page does not require ten rounds of approval to change a button’s color.

While you work perfectly, no single bug is reported from any user after your bi-yearly deployment went live three weeks ago, another team deployed a hundred changes in the last week.

Yes, they might have some bugs in their backlog, some even painful for their users. They have time to fix those while they make income, because users happy to pay for new features (or those new features increase conversion rate, hence paying for their work). They make revenue.

Have your perfectly polished app nobody can access made revenue?

Put it out to the world. Let users meet your creation. You can’t know what great things you learn from them.

Business always has risks. Not acting has it’s risk too. Delay has it’s costs too.

The earlier you are in product development, the more important to go to production as quickly and as often as you can. Even if you think the code is trashy. It should be.

I would rather go to early adopters, who know perfectly well that the software is they about to use is not perfect. This way I still have runway to fix or steer the product into something people will pay for. Refactoring and optimizing later, based on real user data is much more effective anyway.

If you release close to the end of your runway, you just risk crashing into the another end before you could fly. There is a v rotate for a reason, and it is still earlier than the no-turning-back v2 speed.

Have you released something too early? Have you regretted not releasing something earlier? Share our insights in the comments.