Deferred Decision Making

An interesting methodology emerges from the techniques documented in earlier articles. I call it "deferred decision making". Because our programs are designed by contract it means we can defer hard or permanent choices while we determine the value of our program's core logic.

For example, picking a web framework or picking a library for interacting with your SQL database is not a hard problem from an engineering perspective. But they are significant decisions. Whatever choice you make will likely stick with you for the remainder of the project's life. In the past, my projects have stalled out while exploring a near infinite space of inconsequential choices. This is silly. These decisions are incidental to the problems we're solving. They should not consume so much space in our decision making process.

With design-by-contract and dependency-injection you can ignore these choices entirely while your project's in its most vulnerable stage (the beginning). You can assess the value of the problem being solved without the clutter of glue code.

When its time to choose a library you'll find that the choice becomes much easier. Because your program is isolated from your choice of library it feels easier to change later. Whether it actually is in practice I don't know. But there's a tremendous amount of psychological safety in knowing your program is distinct from the incidental complexity that encloses it.