The Rule of Least Power is a design principle that suggests choosing the least powerful computer language suitable for a given purpose. Well, what does this really mean exactly? In the past, Computer Science spent a lot of resources on making technology that was powerful as could be, like a truck among sports cars. Today, we can identify with the idea of going with just the opposite but choosing the right technology with just enough power to get the job done. We can appreciate not going with the most powerful but the least powerful.
What’s the reason for this? When the technology that has just enough power to get the job done is used this allows us to reuse a lot of the constructs. If you write a simple procedure that is easy to write and easy to analyze then anyone can understand and easily extend what was previously done. In most dev shops, you typically choose languages and frameworks that are not only appropriate for the job but also one that is simple in the sense that your existing team can easily learn and understand this technology so the effort to adapt is low.
Why The Least Power?
Using the full power of any technology correctly takes a lot of experience and time. The more complex, specialized and powerful the technologies that you choose to work with it’s the more you will need to teach people who haven’t gone through the experience of using these technologies. This means long onboarding time before you can actually put the developer on billable projects in a manner that would be effective enough for the project to benefit. This means long training hours and time teaching that could be less or better spent doing.
This principle is a great guiding principle even when making high-level decisions on the type of architecture to use, of course in the context of your environment i.e, industry, people/talent, and size of 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.
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.