Declarative Program Design

An interesting opportunity emerges from the techniques documented in earlier articles. Because our program's are designed by contract it means we skip certain critical aspects of our program when writing our logic the first time. Namely querying the database.

Programmers, in my experience, have a lopsided attitude toward performance optimization. On the one hand programmers will readily write N+1 queries and quadratic algorithms without much thought but, nearly without fail, will always choose to SELECT the minimum number of columns needed to solve their problem.

This is a silly optimization in the grand scheme of things. These optimizations are almost never driven by empirical data. They are driven by the aesthetic desires and performance sensibilities within the souls of programmers. To put it bluntly, its a very obvious way to optimize a program and gives a feeling of rigor or quality.

These optimizations are not beneficial and they are far from harmless. Ad-hoc queries proliferate through code bases very quickly. These queries couple application logic to implementation details making migrations to different storage layouts or mediums incredibly difficult. These optimizations also introduce opportunities to miss required ACL controls or tenant scoping or any number of past or future scoping requirements for your resources.

There is nothing in "Design, Simulate, Build" which will prevent a programmer from writing ad-hoc queries, however, I find that psychologically a programmer will be more willing to reach for a fetch_user function rather than writing their own bespoke query. Because you're making the decision of "how to fetch a user" after you've implemented your program. Not during. There is a certain creativity that comes along with writing your program's logic that is distinct from the monotony of implementing your program into the broader application. That's it. There are no other guardrails other than declarative program design becoming the easy default. The path of least resistance.

Declarative program design means we define what a User is once, where a user exists once, how to fetch a user once, who is allowed to fetch a user once, and so on. It simplifies our application's query pattern and allows us to optimize on a simple set of queries rather than the entire universe of possible queries our schema can produce. This simplicity allows us to create prepared statements which cover broad swathes of our application. Prepared statements, in many cases, are a significantly better optimization than reducing the number of columns we select. Remember we can always select fewer columns later when we have evidence that such a change would produce a material benefit to our application.

Declarative program design also means our application's code can scale. It can change in one place and benefit tens or hundreds or thousands of implementations without a significant drain on the programer's time or mental well-being.