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.

Introducing feature flags helps to separate release from deployment, and allow changes to be partially rolled out on a percentage basis and/or to target groups of users. It cannot completely separate these two things as some changes such as database migrations are all or nothing. However, it can significantly reduce the risk of deployments.