How much time have you spent arguing whether you should build something or not, while you’ve been sitting there thinking “I could have built it in the time we’ve spent arguing about this”? Probably more than you’d like to admit. I know I have. The problem is you’re having the wrong argument. The question isn’t whether you should build it; it’s whether you should ship it.

I’ve spent a lot of the last two-plus decades integrating systems, whether that was the goal of the project itself, or just a necessary part of a larger project. Integrations always take longer than you think, even when you take into account Hofstadter’s Law. However, in this time I’ve observed the amount of additional time they take is surprisingly predictable, leading to Beech’s Law:

It’s received wisdom in the startup world that you need to have a staging environment to test things out before going to production. In some cases, maybe even multiple staging environments with different names like preproduction or demo or QA, with different rules about how mature code has to be to go on there. However, I don’t believe staging environments are worth the time, effort, and cost to keep running, so let’s talk about why you should just deploy straight to production.

Product managers spend aeons creating and rearranging them. Delivery managers obsess over their dates and dependencies. People in “the business” plan financials, campaigns, and more around them. But engineers—the people tasked with actually delivering them—mostly moan about them. The engineers are closest to being right, because roadmaps are little more than detrimental fantasy.

Most job specs are awful. They have a “main responsibilities” section filled with vague generic bullet points listing things you’ll never actually do, followed by an interminable disjointed list of “essential” skills and experience that will never actually be needed. Have you ever wondered why this is?