WTF IS SUS DIGI: Modularity
Ackee loves sustainability, and as a digital agency company, we want to bind these two together and build sustainable digital products.
Sustainable digitalization: Modularity
You may ask “What is a sustainable digital product?” or “sustainable digitalization?” in general. And I won’t be providing you any dictionary definitions. I will describe one particular aspect of it instead. One that we in the backend team consider important. Modularity.
When we’ve been thinking about how to pick the most fitting name for this aspect, we started with “separation of concerns” - originally a property of a software that is divided into sections, each responsible for a set of information - a concern. Boundaries also came to mind. We stuck with modularity, because everyone has some basic sense and understanding of what modularity is.
But what we really wanted to express though is that we just don’t care. But what about? Everything? Oh! So that’s why the backend applications take that long to develop! No, no, no. Let me clarify.
Many moons ago
Our backend team in 2016 and several following years, we have changed the tech stack completely and moved from PHP to Node.js. We wanted to do it the best we can, so we spent a lot of time picking, learning and integrating the best libraries - a 3rd party software component you can install and use in your project. The best ORM to communicate with the database, the best HTTP library to connect to other services, the best testing library, the best API technology…
But as it happens in this fast paced world, it doesn’t take much to make all the things that you have researched irrelevant. It has become obsolete. For various reasons - it gets deprecated, i.e. stops receiving bug fixes, security fixes, new features are not added, or your demands for the tool may have changed with the time and previously picked tool is no longer sufficient, new tools, better tools have been created which are now top of the market. Old tools that weren’t better then are now a perfect fit, documentation may no longer be available or tools can become paid and you can’t afford them or just don’t want to pay for them.
So picking the best doesn’t matter. For several reasons. There is usually no overall best, some hammer you can hit everything with. There may be “the best for a particular use case at a time”, but that’s it. Most of the time you usually end up with a list of tools that are similar to one another, all are on top of the list in what they do and most of the time cover all your needs and differ in little things that you probably won’t notice.
There should be no need to. If you pick a decent tool, it usually does its job pretty well. When it comes to the point you need to change it, it shouldn’t be a big issue to do so.
And of course, you're gonna replace it eventually anyway for various reasons. Maybe not today, not tomorrow, but you will. With new experience, your needs will change and you’ll want to adapt.
Let’s talk examples
Imagine you are fond of cats and you want to make them happy. The tool you choose to make them happy is getting them a little house they can live in.
Let’s say you buy them a ready-made house. This low to none modular solution makes it harder to start from the beginning. That is because there are so many alternatives to choose from and it will determine your cats’ happiness for the years to come. Perhaps you like the color of this one, but it’s expensive. Maybe one cat will leave and then the other will live in the big miniature house all alone. Maybe this one has more windows, but this one has the right size. Too many options, too many tradeoffs. And changing parts of it will be hader - what if you need one more window, one less window? This will be time consuming and may end up with unexpected results. And if a part of the house becomes obsolete, you need to leave everything and start all over again. (To be fair, obsolescence is hard to imagine in a cat house, but I am sure you can come up with a fitting example :)
On the other hand, a house built from several parts like Lego, would be a highly modular solution, that does not require that much thorough initiative at the beginning, because you can change it later. And changing things later is made fairly easy compared to non modular solutions. End of life of any part can still happen, but at least you are prepared to make the change. Just by thinking about the design beforehand.
Moving to the present, the backend team is thinking differently now. We no longer strive to have the best, we just have a list of tools that are OK, proven to be good. A developer can pick whatever fits from the list. With one requirement: it needs to be replaceable easily in the future.
Support sustainable digitalization by being modular, by keeping the boundaries, be prepared to replace the obsolete parts, to save your time, to save your energy, to make your products maintainable in the long term.