Technology Demons

Manuel posted an interesting question to post on Design Observations on Big Data for Retail:

Ok, but if you delete all of these technologies from your design, what technologies you'll use ? and how you substitute them?

The answer is two-fold.

First of all, below a quick list of technologies that I try to avoid at all costs in my projects lately. Only when there are strong external forces, I agree to resort to these demons:

SQL Databases (instead: plain files and noDB)
NoSQL Databases (instead: plain files and noDB)
DTC and anything that requires it (instead: design eventually consistent systems)
SOAP and XML (instead: binary formats, JSON and text)
Windows Communication Foundation (instead: messaging, HttpListener or sockets via ZeroMQ)
IoC Containers (instead: design systems to avoid all need in IoC Containers)
WPF and desktop apps in general (instead: HTML5 + CSS + javascript)
Windows Workflows Foundation (instead: proper domain-driven design)
anything non-Git for distributed version control (instead: git)
Aspect Oriented Programming with code weaving (instead: design the software properly)
Mocking frameworks (instead: use simple strongly-typed code; Jeremie wrote post)
N-tier architectures (instead: shallow systems partitioned along boundaries of bounded contexts)
frameworks like log4net, AutoMapper, ELMAH etc (instead: write a few lines of code tailored for your situation).

Second, I don't hold anything against these technologies (except for the cases where tech is being marketed as silver bullet, but that's what demons in all religions are expected to do anyway). I just happen to believe in value that is gained by designing my systems to be independent of these them.

After all, technology should be relevant to the design only when the core problem absolutely necessitates going into this detail. For example, reducing transfer and storage costs via extreme compression of big data or enabling new business scenarios via elastic scalability in cloud).

If however, we are doing something that is not particularly peculiar, then bringing technology to the table (context map) would just complicate everything. I consider to be non-peculiar cases to be, for example, when you have under 100 transactions per second in a single partition, under a few GB of total data for random reads and a few hundred GBs on top for BLOBs - essentially things that you can have deployed at the cost of a few hundred USD per month (including replication and load-balancing). I believe, vast majority of the business scenarios fit this description pretty well.

Yes, this means that vast majority of businesses can easily run on a smartphone (or a cluster of smartphones, if you need continuous replication off-phone)

So, in cases, where tech is not important, why should we couple our designs tightly to the most expensive and complex options among the available ones?

Published: June 08, 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