Simplicity--the Art of Maximizing the Amount of Work Not done--is Essential.

Ref: # https://www.agileconnection.com/article/art-maximizing-work-not-done # https://thevaluable.dev/kiss-principle-explained/ # https://martinfowler.com/bliki/Yagni.html # https://youtu.be/502ILHjX9EE

Simplicity--the Art of Maximizing the Amount of Work Not done--is Essential. I see this as the age old - KISS - design principle acronym. For Agile to be successful code has to be produced and tested incrementally. Keeping the work confined to that 'incremental cycle' not only promotes rapid deployment but "Maximizes the Amount of Work Not done" by keeping out contradictory requirements that always seem to enter the cycle i.e. scope creep. This is truly an art and very essential to Agile Development. I agree with my two colleagues in their comments above.

Many think the meaning of this principle is the inverse of how it is stated (i.e., "minimize the total amount of work done"), which seems like it should mean the same thing (with fewer words), But the statement is REALLY about MINIMIZING the amount of REWORK that would otherwise arise from ANY AND ALL OF: poor quality (i.e. sloppy/careless implementation), OR underengineering (sloppy/careless design) OR overengineering (adding needless complexity). To avoid rework, we need to avoid *complexity*, We make our? design "simple" today (easy to change) by minimizing the IMPACT of having to change it later. This is achieved by minimizing duplication and dependencies in the design *and* making sure we can quickly+easily+repeatably test the result. - More dependencies mean any changes later may impact everything else that depends upon that piece of work;? -?Errors in work that was manually duplicated results in having to manually correct *every* duplicated instance (which is error-prone and labor intensive). So many folks misinterpret the meaning of this principle that I blogged about it (over a decade ago) at https://bradapp.blogspot.com/2006/05/simple-aint-easy-myths-and.html

We achieve a goal by expending effort and resources. If we expend more effort than we need to then we have wasted effort and/or resources. This agile principle is highlighting an ideal that we should be striving for. But to me what it is really saying is: 1 - We will ALWAYS waste some effort and resources however hard we try not to (probably in any endevour) 2 - Most of us are REALLY inefficient in achieving our goals ALL the time. 3 - We need to be aware of this reality and constantly hunt for opportunities to identify, measure and improve our performance This of course applies to individuals and groups. In the context of software development, this principle has less to do with WHAT you are making but HOW your are doing it! The whole idea stems from the observation that often we concentrate on the WHAT and completely ignore the how. So we dont get any better (more efficient) at delivering stuff. Of course teams do improve the way they work over time, ibut often the rate of improvement is very poor compared to what it could be. I think in practice this principle is alerting us the possibility that there are HUGE opportunities for us to mine by thinking about the HOW of what we do when we try to deliver stuff!

Or just do not over-engineer things. It really depends on the circumstance... there does not exist a one scenario fits all