These days it is all about better, stronger, faster etc. The global populous can't seem to get enough of what they have. We live in an era of instant gratification. Push button dopamine triggers. It is all quite fast, euphoric and sometimes even exotic. Never has there been a time when the famously quoted statement of "We are living in a material world and I am a material girl" has been truer. On the flip side if people were conscious enough, they'd realise they do not need 3 different ipads, 2 different cars or 4 different mobile phones. Not only that but by reducing this unnecessary waste there are benefits to be had aplenty.
Although Minimalism is a more general term, it's benefits translate well into the tech industry. In our industry, we all love complexity, for in complexity we find our challenges and those challenges inspire us towards creative solutions. Overtime, a segment of the industry has misunderstood this love affair of complexity. In that, it sometimes directly translates to implement n number of components of a delivery infrastructure or n number of modules for a new server side process.
Another more toxic segment, establishes fake credibility, by deliberately introducing complexity into the solution. As a customer it may inspire some confidence in you, if you got 20K lines of code instead of 5K, however do note that the tech is NOT the sales. Con- games do not work very well. Adding more things into your solution will introduce complexity, and complexity will have long term disadvantages. It makes your solutions less maintainable and expensive to manage.
Some teams just cannot help themselves and suffer from a disease called Over-engineering. This also adds tremendous amount of complexity to a solution/system. It not only costs more time and money but also, there lies a danger that the actual use case and requirements may be ignored. The process starts to focus more on what is right instead of what is required.
The KISS principle, assists the concepts of minimalism very. Sure, minimal doesn't always mean simple but in most cases than not, this relationship holds. For example in the case of data modelling and database design, contrary to what is taught in school, it doesn't always pay off to aim for a third normal form. Sometimes, there is no benefit to it.
In terms of software development, it is a well known fact that if the software is decomposed to its most atomic form it helps unit testing quite a lot. This means that Software Fragmentation is directly proportional Unit Testability. But in practice, there is always a balance to be maintained. Too much fragmentation is not necessarily a good thing and may even have negative performance implications for software developed using certain programming languages. Additionally, this can also make your solution more difficult to maintain.
The afore mentioned concepts, and other traditionally taught/read concepts like these, are susceptible to abuse. More often then not they are and that usually by people who would shake some holy book in your face. A minimal and clean solution is usually the one that can be understood and explained simply. If it takes 20 diagrams and 30 presentation slides to get your basic idea across, beware!
To summarise, it helps to be conscious of your solution's complexity level. Where possible, use appropriate metrics to measure this for example, in case of software engineering a cocktail of LOC, cyclomatic complexity, static analysis etc. Always ensure that the interfaces to your solution/system are limited. This funnels all parameters/data through known points. This will prove priceless for testing, debugging and other diagnosis. When looking at requirements, break problems down to their simplest form. Do not worry about the sugar cube, worry about the sugar granule. An ocean is made a drop at a time. The question a team needs to ask itself is what is the minimal requirement for achieving a particular goal. That mindset should keep a team on track.
So keep it simple and keep it minimal. Prosper!