What if Minimalism was applied in Software Engineering?
We all have heard of the minimalist lifestyle and some of us have explored it more by watching videos and listening to podcasts. Some of you have been living this lifestyle for quite some time.
What is the main principle behind minimalism? It is about having fewer but high quality things without feeling the need to de-clutter; it is also about re-using specific items to serve multiple purposes. It is about focusing on what matters to you in life, and de-cluttering is how you accomplish it. This is how I interpret the minimalism.
Why am I writing this article? As I was de-cluttering things in my house, I asked myself some questions in the context of software engineering.
What if the minimalism was applied in the field of software engineering?
I am?not?directly talking about keeping the code simple and cohesive. I am?not?necessarily talking about the software principles and design patterns. I am?not?talking about the monolithic vs. microservice applications. What I am zooming in on is:
I am talking about having a simple development stack list, but slightly longer capability list.
For?example, I am talking about having the following development stack:
With the following capabilities:
领英推荐
Is this for everyone? NO, it is NOT. Similar to how the minimalist lifestyle is not the best choice for everyone, this type of software engineering approach is not efficient for every company and every product line.
Yes, if you want to optimize and squeeze the most performance at the enterprise level and introduce high elegance, you pick the best tools for its job. However, there are companies and product lines that do not require this. Their traffic may not be high enough. 200–500msec may not make much difference for them.
For example, in the above list I mentioned the caching as a capability but the development stack list did not include any traditional caching tools/services. For example, you may decide MongoDB is your database choice and that you will also use MongoDB for “caching” purposes with some TTL on those records. MongoDB may be 20msec slower than the traditional caching service (i.e. Redis),?but you have one less tool/service to worry about, maintain, figure out the cost structure, and figure out from security point of view. Your Java code can still have a module for caching but what it is doing behind the scenes is communicating with MongoDB; essentially the code would be written in a de-coupled abstracted fashion but the collection of tools/services is smaller.
Similarly you can improvise the pub/sub approach with the limited number of development tools/services. Yes, it might be slower but if the speed is acceptable for your business, you are gaining a lot from the maintenance, simplicity and security point of view.
I will say again: This is NOT for everyone. However, if it is for you, this could be right for you for longer periods, or it could be right at the beginning and then you revisit it and see where the future takes you. There is a saying: “Build it, use it, and then optimize it later”. This does?not?mean that we hack everything without having any elegance and cohesion in the code. It means that you think about the long term design and you implement what’s necessary in that first iteration.
Let me tie it back to the minimalist lifestyle that I used at the beginning of this article. In the minimalist lifestyle, you don’t buy a laptop for gaming and another laptop for traveling and another one for video editing. You don’t buy a dish set for your everyday use and another set for special family occasions. You don’t buy a daily economical car and another car for weekend spirited drives (a hard one to follow for us car enthusiasts).
Similarly in software engineering if you were to follow the above summarized minimalism, you would not want a separate tool/service for every type of software architecture/pattern. Yes, this goes against our desire to optimize and pick the best tool/service for its job, but I am just saying: What if??Asking this question may not trigger you to go in this direction, but it should make you reflect on things and revisit why certain tools/services are used.
Thank you for reading this article. Keep geeking out!
Almir Mustafic