What Is Essentialism, and How Does It Make Software More Efficient?

Last year, I enjoyed reading a new and provocative book that explores a new way to think not only about some aspects of life but about everything.  Essentialism: The Disciplined Pursuit of Less by Greg McKeown brings this new perspective, but is it right? Can we apply it to software development? The short answer is: yes. Furthermore, you can do it more efficiently, and in this post, we'll explain how with the essentialism methodology.

When we talk about software engineering, it might have several approaches and definitions. This post will use my favorite one from Modern Software Engineering by Dave Farley.

"Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software."

Where efficiency is not an optional part of the process of software development, and when we talk about efficiency, we also include avoiding the waste of several resources on it such as powerful computers and people's time.

That is where essentialism helps in the process, mainly because it starts with three core principles: 

• Individual choice: We can choose how to spend our energy and time.
• The prevalence of noise: Almost everything is noise, and very few things are precious.
• The reality of trade-offs: We can't have it all or do it all.

If you still don't follow me, let's take a step back and talk about the enemies of good software development.

The Obstacles to the Software Process

Last year, Forbes enumerated sixteen obstacles to creating promising software in 16 Obstacles To A Successful Software Project (And How To Avoid Them). We will highlight some as follows:

• Hyper-focused planning and design
• Unclear or undefined client expectations
• Overlooking nonfunctional requirements
• Not aligning early on the "must-haves"

Does it sound like a paradoxical problem? How can we spend a lot of time planning something we don't understand? We're putting energy into something that does not help us to solve the problem or to boost the right target.

That is issue number one: how to spend time and energy on the correct problem and spend energy on what matters. That is where software development needs essentialism. We need to find the highest point of contribution: the intersection of the right thing, time, and reason. 

The highest point of contribution

Clarity is part of the process of archive success in software development, and the power of choice is crucial for it. The choice is an action that defines where you'll put the energy. Being optimal of those options can help you get close to your objective.

The energy on essentialism vs. no-focus

The action of choice is strict, mainly because we need to think more about the yes, including the several negatives we need to say. It was one of the most challenging points of my life; initially, I related the "yes" with open opportunities like the Yes Man movie.

It is a battle between the fear of missing out (FOMO) and focus. It might impact you as well. I recommend trying it out and see if you are like me: that the "no" gives you freedom. Again, it is not easy. I still fight it, but find it necessary - actually, essential.

As a software engineer, saying no also includes avoiding the newest technology in the market because this ally might become an enemy and make things more complicated than necessary.

Essentialism Is Saying “No” To Many Things, Including Over-Engineering

When we compare the software development tools with ten years ago, we have many options that are supposed to make our life easier, including methodologies, frameworks, and tools such as Kubernetes, microservices, etc.

But why do I use the word "suppose"? With many tools, it gives us options that make our life harder, and exploring the wrong tool makes things more complex (see "Complexity is killing software developers" by Scott Carey).

In software development, there is no silver bullet: accordingly, it is ok not to use microservices, Kubernetes, and even-driven and hexagonal model architecture all the time.

When we talk about microservice, it is only possible to think about the two books on the topic by Sam Newman. But even he wrote "Should I use microservices?" where he does not recommend for use on a new product.

The topic here is not to blame new trends or technologies. Those are amazing and help at the proper time. The first question is how far those are from our goals. Essentialism can help us go for it with simplicity.

The Bare Necessities

When we talk about software decisions and design, we think about software architecture that has two laws:

• The why is more important than the how.
• Everything has trade-offs.

Once you find the goal and where you want to put your and your team's energy, simplicity can help decrease unnecessary software development risk. I'm not against innovation: I love it, but exploring the wrong tool can impact you to go to the flawed site.

Starting not using those new and fancy techs and exploring more straightforward and fast ways to go, such as monolith or not using Kubernetes, might be a good solution for the beginning. 

Being adaptive is the fundamental part of the Agile process, and software on production is part of it. Remember, not starting with microservices does not mean not using them shortly; you can explore them when necessary. It also happens with the hexagonal model. Do you need all of those layers to start? Let's start with three, such as an MVC.

Start simple and evolute your software and architecture: it is part of evolutionary architecture. The software needs to be adaptative and not see the future.

In summary, looking for the bare necessities is a good choice if your software architecture has a song. We explored the architecture decision, but regarding methodologies, we also have human interactions, which include meetings. Let's talk about them as well.

Saying "Hasta la Vista, Baby," To Endless Meetings

When we talk about software development, we need to include the more worthwhile resource, primarily because we cannot get it back once we waste it: time.

When we talk about time, on the one hand, we have over-engineering; on the other, meetings, meetings, and more meetings. We must remember that it is a group of people stopping to follow a goal. 

Save people time by making sure the prerequisites of the meeting are in the description and exploring the meeting notes to register the decision. Please pay attention to the time of the sessions. There is Parkinson's Law that says work will expand to fill the time allotted for its completion.

Summary

When we talk about software development, ensuring that you're doing the right thing at the right time is crucial for the key to delivering. Essentialism is a great partner to make it happen, mainly because it decreases the chance of overengineering, endless meetings, and waste.

Even categorized as a non-IT book, "Essentialism: The Disciplined Pursuit of Less" helps give guidance to meet simplicity and trust more what an uncomplicated solution work once a smooth software is a software with less risk of misunderstanding and becomes a legacy code faster than usual. I hope that you enjoy the book as I do.