I first heard this phrase during an Agile training program, that sounded really cool, but I was thinking how can we possibly apply that to my software engineering work.
It’s one of the twelve agile principals.
What does it mean?
According to my understanding it simply meaning doing only what is necessary and required. For that we have properly understand the user’s requirements and required value and work only to add that value, nothing more nothing less.
Why do we do that?
Well in simple words you save a lot of time by doing that. Time is money, isn’t it?
It will improve your timelines
Most of the software engineering projects suffer when meeting timelines. So why do we do something that has not been expected. Yes, it is good to always add more value, but what if that value is not required by the user? Our effort will be lost.
In order to understand the optimum set of requirements(not minimum) you should have close collaboration between your users(product owners) and you. Identify to the user stories in the optimum granular level, so that product owners/users can clearly set the priorities correct. So that the dev team can deliver working software as soon as possible. It is part of the dev team as well to argue on the priority of the stories. With the collaboration users/product owners and the dev team can come to the optimum set of requirements.
Working on and delivering the most important things means that adding the most value to the product. Which also means utilizing the budget effectively to maximize the return on investment
Requirements tend to change with time, so why do you want to just throw away you nice additional feature?
Simple words, ‘Ask the user, get the feedback, develop the feature only if they required’
Code quality will be high
We love to build super features, a Todo app which can also save the earth from aliens.
We have to keep in mind the coding is an art. Simpler and minimal the better.
If it is not practically required, we don’t need to handle all the hypothetical edge scenarios(but don’t let those to be forgotten as well). Make sure to always have support for future improvements by preserving the Open Close Principal.
Whenever you design, code and implement remember to think twice, or ask someone and maximize the work not done.