your team.
For example, building microservices versus monoliths requires a different set of skillset and experience in that problem domain to be effective. Likewise designing with a NoSQL database versus a SQL database requires different experiences and not every system needs to be just one type every time for every problem. Using the full benefit of an approach requires a higher degree of talent so choosing an approach should be fully analyzed with purpose and least effort/power required in mind.
Defaulting to monoliths for every single system isn’t a rational thing to do as a solutions architect. It’s like choosing Node.js to build every back-end service regardless of purpose. With this mindset, you’ll definitely eventually end up using a shotgun to kill a mosquito.
Sticking to the Rules
The Rule of Least Power comes in at every stage in product development. We can find it beneficial to do the simplest thing to solve a given problem. It’s just like our KISS principle, remember, keep it simple.
While KISS principle lives close to writing code although it can be extended to other areas, the Rule of Least Power principle is about picking the right technology. With the idea that we should choose the technology with just enough power to get the job done the right way. Like KISS, The Rule of Least Power also extends beyond choosing a computer programming language but as demonstrated before choosing an architectural approach, a framework or even a library.
Experience shows us it’s better to start simple and incrementally build on software as requirements are introduced. What we think we need and what is actually needed are often different things in the end.
With great power comes great responsibility, time and effort. The more complex a technology the harder it is to use or even swap out later.
Shotgun Mosquito Effect
Let’s look at how to analyze and put the Rule of Least Power into practice. Why favour a less powerful technology over a more powerful one. Let’s say we wanted to build a front-end application that simply displays a list of information to the user, perhaps this is as simple as binding data to DOM elements that you want to repeat. With modern front-end technology in mind, you would probably list the most powerful frameworks to date. Angular, Vue and React as appeared in more versus wars than I care to count.
But they are not without a purpose, with similar and overlapping features it’s easy to get caught up in the debate. However these frameworks aren’t better and worst than each other, they’re “perfect” just the way they are and like everything technology, they were built to solve somewhat different problems.
However, with only the rule in mind simply choosing one based on your given goal and ignoring a wide array of other factors when choosing the “right” framework like documentation, community support, maturity, license, long term support and even popularity in the job market.
To take in all the boilerplate code of the Angular framework to just do a simple task is quite an overkill. Angular is great for building enterprise applications from the start not so much a necessity when building a small simple application. Choosing vue.js or react for this simple task and just that would be appropriate given the principle. Bare in mind, knowing what this software will look like in mature stages would give more guidance in your selection.
Final Thoughts
Stick to the rules, keep it simple and choose the technology with just enough power to get the job done. Use the simplest programming languages, frameworks, and approaches. Develop on your software as you gain a better understanding of the problems in your domain.
