design patterns - Reconciling the paradox of YAGNI vs foresight -
i've taken courses , read purposes of yagni. but, principle whole has never sat me. introduces logical paradox.
as hypothetical, you're designing framework intend scale forward. yagni (and possibly tdd) encourage focus on now. make work foreseeable hardware. after all, requirements future fuzzy and, well, in future.
but, inherently limits framework's viability. , in hypothetical, have foresight know future hold. may worth time prototyping , working ahead, knowing down road. after all, essence of framework facilitate functionality across environments-- how can designing framework and adhere strictly yagni principles?
i'm not sure if i'm asking concrete on "how use yagni"-- may more philosophical that. might asking more seasoned developers in industry line between yagni, antithetical principles, , best practice. yagni enforced? regarded? or our schools teach because it's in our books?
thanks.
yagni important principle in real-world development , maintenance of large applications, number of reasons. here compelling:
technical complexity when working on industrial-sized codebase, seasoned developers learn considerable reluctance accept technical complexity system. should not start paying implicit overhead of technical complexity before need it.
requirements churn may think have clear idea of future requirements of system, may wrong. statistics suggest 35% of features described product owners 'must have' project never implemented. trying anticipate future requirements , of technical work new leads wasted effort.
qa feedback loop time development on non-trivial technical system, there bugs. inescapable. finding out bug on day of creation vs 1 year later makes difference in development cost factor of 100 according studies. typing code cannot caused execute through interaction ui 'in case need later' sign of inexperienced developer.
in summary, best code sticks yagni principle time, , best agile teams aim this. may think making code easier work with, more flexible etc. if show foresight, never case. code @ easiest work when simple, keep way.
Comments
Post a Comment