Ever spend hours engrossed in solving a problem to meet challenging requirements, only to discover later that the trickiest constraints were unimportant? I’ve fallen into this trap myself multiple times and watched others do the same. So apparently has SpaceX, to the extent that they addressed it in the first two points of a widely shared algorithm used at the company for improving their engineering process:
- Make Requirements Less Dumb
- Delete the Part or Process Step
Make Requirements Less Dumb
Requirements that place constraints on a design might not make sense. In software, they could be too forward-looking (support a billion users), a poor fit (have the database send emails) or even impossible (zero-latency change notifications). With good, iterative communication between customers, sales, product managers, and engineers, it’s possible to delete or modify these sort of requirements, thus preventing engineering effort from going towards solving the wrong problems.
Delete the Part or Process Step
Struggling with the consequences of including something in a design? Remove it! The second step removes internal constraints caused by the system itself. If your service writes to a log file, now you need a disk, log rotation, and disk-space monitoring. If you ship a client component, you need an update mechanism. If you implement a component in a second language, now you need to handle that build process, toolchain, updates, CVEs, etc. Eliminating and simplifying components frees your team from any derivative concerns, avoiding a common fate of mature software systems where managing the internal complexity and constraints becomes the dominant cost of development.
This Algorithm Runs In A Loop
Fixing requirements and minimizing internal constraints is not just something to do before development starts. It’s also critical to revisit periodically: as the project progresses new information and a deeper understanding of the problem space will reveal new opportunities for improving the outcome by changing or eliminating requirements or internal constraints.
It Takes Effort
Constrained problem solving is a core aspect of engineering, and an aptitude and love for it is what draws many into an engineering career. It is one of the fun parts, which can make it difficult to step back and reconsider whether the requirements are a necessary part of the problem, or whether internal constraints imposed by existing components really need to exist. In the real world, unlike with puzzles and games, often the shortest path to a solution is to adjust the requirements. If you’re taking a break from some difficult problem solving to read this article, before diving back in, ask yourself if deleting a constraint could help.