Abstractions and design

Developers as a group tend to value clean abstractions and models. Through observation of generalities and commonalities we create designs and solutions that solve the needs of our target audience. If they just stick to what we agreed to was the truth, that is. If they conform. How many times have you said, or heard developers say: if only we didn't have to deal with the customers. With the implication that without these customers' meddling we would be able to build a great system, perfect even.

There is probably some truth to that. Given a well defined problem, where the requirements never change, we would have an easier time of designing and implementing a system that supports it. The problem is that the system would perfectly support the needs as defined then, but that "then" has probably died and been replaced by a new now. And let's face it, the requirements are worst understood at the beginning of the project, the annoying changes are most likely accommodations to the fact that the described, idealised, reality didn't match the actual reality. So given the time to work in peace we would probably build something that prefectly supports imperfect descriptions of past needs.

• • •

The solution isn't to build infinitely flexible systems. We already have that, it's called a general purpose computer. The application you're developing is probably meant to meet specific needs of a specific target audience. Deferring decisions to the configuration and implementation phase will most likely increase the complexity of your system, and while it will be able to support a wider range of use-cases it will do so at the cost of being an efficient, considered, solution to specific problems.

If your goal is to eke out a living as something similar to an IBM, Salesforce, or SAP consultant, well, we probably don't share the same design sensibilities. That doesn't mean that you're wrong and I'm right, it just means that I probably would hate the resulting system, both as a user and a developer.

• • •

Neither is following every whim of your customers a viable solution. At least not if you are responsible for the design of the solution. And especially not if your application is used by several or maybe all of your customers, e. g. it's your product.

The solution, of course, hides between these straw man-esque solutions. And depends on your ability to make the correct decisions on whether to specifically implement support for something, or introduce flexibility to accommodate variance. And that ability depends on expertise.

That expertise might be technical, it might be domain specific, it might be tied to an understanding of your target audience: how they work, or how they earn their money. But it must also be grounded in an idea of what your system is, what it is in the process of becoming, and what your goals are for its future. Acknowledge that both the system and the world around it are living things, and that the pressures that are put on it, and by extension you, always will be changing. If not, that's probably because people have stopped caring, or process has isolated you from the specific realities of its use. Neither of these things are good. Because what's the point of acknowledging thate things change if you don't also observe said change. The design process must not only take the present into account but also anticipate, and create, movement.

It's not easy, and we'll stumble, take wrong turns, and make silly pratfalls. So create systems that are amenable to change. Try to anticipate movement, but don't build towering abstractions to support hypotheticals. Don't introduce unbounded and ill-defined flexibility, because then you will lessen your knowledge of where you are, and make it harder to move forward. Systematise and model behaviours and data so that you can reason about your system. But value the lived realities of your users higher than the categories and processes you have designed for them, but in turn, don't confuse that with letting your users dictate how the system should be designed.