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?

If you thought about it for long enough, you would invent domain-driven design. This is a talk I gave at DevLab ‘21 about deriving domain-driven design from first principles to demonstrate that it’s an intrinsic property of well architected systems.

“Static typing” and “strong typing” are frequently conflated, as for many people a statically typed language implies that programs written with it must also be strongly typed. That’s notionally true as the variables themselves have types, not just the values, but I’d argue that most statically typed programs are actually fairly weakly typed.