Target Function of the Change
I strongly believe that change must have a purpose, and the purpose should be defined before we start the change. This belief is inspired by my subjective experience and the book “Building Evolutionary Architectures” by Neal Ford, Rebecca Parsons, Patrick Kua https://www.amazon.com/Building-Evolutionary-Architectures-Support-Constant/dp/1491986360.
When we talk about the common technology landscape (keeping joke technologies like brainfuck aside), each technology and each architecture pattern has pros and cons. Some have more cons than others; for example, Java in many cases is a better choice than PHP, but still, there are many cases when PHP is the optimal choice.
Microservice architecture is considered a better choice than a monolith. But I know several cases of “microservice hell” and a lot of cases where monolith apps have been doing the job well for decades.
Today in some LinkedIn post I saw a picture that triggered this post. The idea of original post was that code piece no. 1 is bad and no. 2 is good, because it is more flexible.
While, in general, I probably like the second code piece more, I do not see clear definitions of good and bad. As an exercise, let me try to define some criteria that may make the second code piece (see picture above) is bad.
Latency: minor, but still could be valid in some applications. The first code piece works a bit faster. This is not critical for browser applications, and not critical for most server-side applications, but in some cases, it could be important.
Flexibility/modularity: let’s imagine we additionally need to have +/- operators. Or ⊕. The second code piece could be modified to support this, but this is one more refactoring. This brings us to an observation made by one of my colleagues: “when you are stating ‘I made the code more flexible in general’, not having in mind a particular case, the real change always came from a different side that you do not have in mind, and you have to change the code one more time.”
Supportability: The first code piece is easier to digest and modify for junior developers. It is just smaller. A developer who studied the basics of JS could easily understand the first code piece and make modifications. The second one requires way broader knowledge.
Again, I am not advocating any solution. I am saying that in software engineering, first we need to define good and bad in the context of a particular system, and only then build a roadmap from bad to good. Discussion of a type “Is Redis better than Postgres” without context, in a vacuum, leads to nowhere.
