Don't Build Your Products Around Technologies. Build Technologies Around Your Products

This post was originally published on my blog

I had somehow assumed that this is something people learn, once they get burned by a few incidents. Yet, time and again, reality finds its ways to prove me wrong. So, I am compelled to say it once again:

Don't build your products around technologies. Build technologies around your products.

There was a time when I could swear my allegiance to any tool, framework, or library which happened to be at the heyday of public attention. I would toy around with it, talk about it, proclaim it to be the one and only solution to any problem, or use it to design solutions for problems I wouldn't really have. That is, until the company/community behind it, lost interest in moving the technology forward. The technology would quickly lose its coolness factor, die out of public interest, and get replaced by a new one, supposedly even cooler. Usually, it goes like this:

1. Company ABC has a product problem
2. ABC comes up with a clever solution: XYZ
3. ABC decides to open-source XYZ
4. XYZ becomes an overnight hit
5. Other companies adopt XYZ for their products
6. With so many use cases, XYZ eventually becomes a burden to maintain
7. ABC gives up and moves along
8. XYZ dies out or gets replaced by a new shiny toy
9. Parts of XYZ eventually make it to a standard, but years after its fall from grace

This cycle would repeat a few more times over the following years. And every time the same. A technology would appear from nowhere, quickly become overhyped, only to die out and get replaced soon thereafter. It becomes a burden. And, while refactoring is fun the first few times, the bigger and more mature my work got, the more difficult it became to justify the costs of eventually having to get rid of this burden, once it died out.

This is the reason, why nowadays, I would try to stick to a stack that first-and-foremost, solves the concrete problem at hand, and second, steps on the shoulders of standards. Indeed, my weapons of choice might not always be the fancy ones that one reads about on Medium. They might not have an interactive documentation site or a vocal Twitter community, but they get the job done, and they have proven themselves over the years. As for the fancy ones, I do play with new things every day, and many of them find their way in my projects. Yet, just like in investing, a certain level of risk assessment is needed. This is where the good architecture comes into play, clearly distinguishing components from one another, and abstracting dependencies away behind generic API contracts.

Final Note: A great technology is one that helps you solve a particular problem without becoming the centerpiece of your product. It conforms to standards and is thus easily swappable with any other one that does the job better. For those that don’t, it’s your responsibility to abstract them away with code that does. Don’t sugar-coat a piece of technology just because it’s nice to play with, or because the community tells you so. Or in other words: don’t put all of your bets on one thing, but rather, build your product as a collection of many loosely-connected things. Let new libraries, tolling, and frameworks sprinkle out of your particular needs instead. This is how standards get born.