Always, Never and Context

It sure would be nice to work for a client that knew exactly what they wanted and why they wanted it. Then again, if that were the case, I probably wouldn't have a job because well defined problems are easier to solve and don't pay as much.

The more challenging case is when I'm helping them by delivering an iterative solution that works for them in two important ways: 1) It alleviates pain and 2) It actually clarifies the domain problem. It is the software equivalent of a picture is worth a thousand words. Since we deliver software every 30 days, the relative cost is low enough to have confidence to take a step in generally right direction instead of standing still waiting for a concrete requirement to materialize.

A logical consequence of being in this situation is that when architecting the system to support the "known knowns", there is simply not enough information to declare "Always" or "Never". The reason being that the problem itself or a solution to the problem is not yet fully understood. It is the context that is missing. This is actually OK because an implementation can evolve as does the business case. One example of this could be that users are "misusing" your application in unanticipated ways, leading to an an opportunity to "pave the bare spots".

During each iteration of the solution, there should be enough of a cost/benefit analysis to help arrive at an appropriate implementation. Part of this analysis could take into account concepts like "simple as possible, but no simpler" and Behavior-Driven Development to define the progression.  I can say with more confidence, however, that the one input that must always be present is domain Context.

Which leads me to a more concrete example: "An N+1 query is never correct". This is certainly a well known performance antipattern. But the problem here is one of context. This statement has no insight into the domain problem it is part of solving. There is no business driver inputs that allow such a statement to be true in all cases.

Consider that your stakeholder has provided you with what they know to be currently true that lets you derive:

• N maxes out at 2.
• N, at an order of magnitude bigger than the largest known business case, executes < 1ms.
• An AOP slice needs access to each N for required non-repudiation auditing.
• A sql solution is not testable at a necessary confidence level that the DAO language can provide.
• Only one developer on your team has expertise to write and maintain an optimized query.
• As you build out a backlog of functionality, it is very likely that a near future refactor will negate time spent developing a more performant solution. 

Without such inputs setting the stage, you are flying blind in a way where absolutes tend to become negative attributes. Solve the problem given what you know, stay loose and don't be afraid to refactor when the context changes.

To borrow a phrase, Context is King.