Design Obsessions

I had a lot of failures in my past development experience. Most of them were caused by being completely obsessed by some cool technology or a trick. These things were so appealing that desire to use them became the central idea of an application.

Among the failures I had in my development, these ones were caused by design obsessed with some technology:

Design driven by principles of UI composition and Flexibility, where you build ultimately flexible CRM system with any number of fields, queries and forms.
Inversion-of-control-container driven design, where you design a system by dropping a large pile of services, controllers and managers into the IoC container, and then letting it resolve a complex graph.
ORM-driven design, where you design your "business objects" and the rest of the system is wired almost automatically.
CQRS-driven design, where you take this principle as architectural guideline and end up with a complete mess of messages and views.

Lesson learned - if central idea of your design is about technology, then such system will become a slave of this technology. All advantages and limitations of such technology will eventually become forth and strike you really hard.

If you start your system design by assumption of using a certain framework, database or tool - you are already paying a tribute to this obsession. It is unavoidable to some extent, since we are limited by knowledge and capabilities of our development teams.

However, we can reduce bad side-effects by trying hard to focus on the idea that is worth becoming the center of your application. As you probably have guessed, this idea is about solving the real-world business problem you have at hand (granted that this problem is worth solving). Examples of such problems are:

helping business to optimize it's pricing strategies across hundreds of thousands of products to increase turn-over and reduce amount of inventory that is thrown away;
enabling a company to serve millions of its customers better by allowing behavioral analysis of each individual and suggesting healthier and cheaper products;
helping a hospital to serve it's patients better by providing more efficient ways to diagnose patients, schedule available resources or collaborate on information about treatments and medications.

Technologies, stacks and approaches are merely replaceable tools that help to support such solution (even if tech is as cool as cloud computing, event sourcing or $YourCurrentlyFavoriteTechnologyHere$). Pick them consciously and don't let them become the core idea behind design of your solution. Such obsessions are among the most expensive ones. If you have too many - you can even end up with a severe case of analysis paralysis.

While designing systems we try to use all cool tech we love. Design obsession with solving business problems is better.

Update: if you want to hear a bit more on the subject and my mistakes - check out Episode 8 of Being The Worst Podcast

Published: September 21, 2012.

🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out