Less is More

By reducing the complexity of our architectures and the number of tools we use frees our minds to focus on what drives our applications and businesses Less is More - https://en.wikipedia.org/wiki/Less_is_more Marie Kondo- https://en.wikipedia.org/wiki/Marie_Kondo Minimalism - https://en.wikipedia.org/wiki/Minimalism

By reducing the complexity of our architectures and the number of tools we use frees our minds to focus on what drives our applications and businesses

Less is More - https://en.wikipedia.org/wiki/Less_is_more
Marie Kondo- https://en.wikipedia.org/wiki/Marie_Kondo
Minimalism - https://en.wikipedia.org/wiki/Minimalism

Welcome back to The Byte. In this episode, we will talk about less is more and I was always under the impression less is more was always a Unix term that Unix-Linux communities came up with. And I was actually doing some research which you should before you do such shows. And the term actually comes up from a poem by Andrea del Sarto, the Faultless Painters back in 1855. So I was like, "Okay, that's interesting."

But then the less is more was also applied to building architecture in 1947. This was also interesting where they tried to reduce the complexity of designs, make it cleaner, less structure, white, try to make it more open, more like the Apple design that comes from this type of structure. And then, if we look at the Unix part of the world, I guess, less is more is like the less and more commands were actually the same functionality.

Now, I want to take this a bit further and say less is more, we should also apply this to our infrastructure, our tools, our application code. Currently, we're just getting bloated with so many tools and complexity in infrastructure. We're kind of losing our way in all these tools. If you've ever watched Netflix, Marie Kondo, she's like the Japanese organizing consultant where she goes to people's houses and helps them pack things away and like thanked them for being serviced. We should do this also to our IT departments, not just infrastructure but the entire IT department.
I've been to a couple of customers where I asked them, I'm like, "Okay, so how many monitoring tools do you actually have?" And they took a while, came back. I think they had about eight different monitoring tools. I'm like, "How can you like have an overview of all these tools monitoring, just for example, as a single business? This is super difficult. I mean, you should limit the number of tools." I realized large businesses, you won't get down to one but at least cut it down to at least two or three. 10 to 12 tools, come on, you'll never be able to have a global view if you have so many tools.

And then if we go through all the other tooling as well, if we look build tools ci/cd and Jira and Confluence, all these things. You get issue tracking. How many tools do we use daily to do our jobs? And it really weighs on us a bit. If you look at the minimalism approach where you try to get everything out of your life and try to remove as much as you can to free your mind to be able to do more things, we should be trying to do this to IT as well, in my opinion.
Because if we're spending so much time on the tooling, how can we spend any time on actually building things and actually have the capacity to design new things and come up with new ideas in how we can build our application better, focus more on the business on the application side, and how we can deliver more value to our organization? And how can we do that? Just, for example, the monitoring example.

Let's just focus down on one tool for monitoring for your organization. Try to bring it down to one tool and say, "Okay, this is going to be standard across the organization. You might have some variations. You might have some other tools that like complement this tool but everything should be focused around this single tool."

And once we have that nailed down, we can go down to the next tool. For example, like your build tools or go back to git. What's your git repository? Do you have a single repository? Do you have multiple different tools? Try to consolidate that down. I realized in large organizations, this is a huge ask but just think about in your department if you can make this choice of limiting the number of tools you have and being able to focus more on what you're developing and what you're building rather than filling out pages and pages of issue tickets and writing huge Wikis about all the different tools you should use and the processes. Wouldn't it be much better if we could just focus on building something, developing and bringing value rather than tools?

Think about it. It's just more of a brain teaser. Less is more where we apply minimalism to our infrastructure and tools. I've been trying to do it with my personal life. Try to limit the amount of software I'm using and limit these different tooling I'm using and it helps quite a bit. It freed up my mind quite a bit, and it has also freed up my workflow.
My workflow has gotten quite a bit more efficient because now I don't have to jump into three or four different tools and log at different ways and do all these different things. I have two tools for this podcast, that's it. I record it and then I transcribe it. Done. Whereas previously with my blog, I was using four or five different tools to write the post and do all these things. By limiting the tools, it actually increases your workflow. It allows you to focus more on the product.
Let me know in the show notes. You can comment on Anchor and let me know. Raise some questions, provide your feedback, what you think about less is more and that's all for this episode. Have a great day.
 
 
Brian Christner