Unnecessary Until Proven Required
By Ryan Tomayko under Theory on 10. July 2005A big part of what we’re all trying to do is bring the complexity of our systems and working environments way down compared to that of the established industry. Complexity is a tricky concept, however, and I believe it is wise to understand when it is and isn’t okay to play the “too complex” card.
Bill de hÓra introduced me to the idea
that the that’s not simple
argument is often not very different
from the that won’t scale
argument we’ve all come to despise:
These days we are all complexity experts and simplicity mavens. Once upon a time a popular way to trash somebody’s technical design without having to bother to present a cogent argument was to point at it and say it would never scale. Today we just can call designs we don’t like complex - that’s even better because while it’s unlikely to happen, you can actually have a meaningful conversation about scale. Complexity on the other hand is comparatively vague - indeed there is only one simple definition of simplicity for software.
But David Meggison does an excellent job of describing why the simplicity argument is a healthy way of thinking about systems anyway:
… it’s really a fundamental change in the burden of proof (in the popular sense of the obligation to defend a position). With the rise of agile development and worse is better, we’ve shifted from “required until proven unnecessary” 10 years ago to “unnecessary until proven required” today, and I think that’s a change for the better — after all, if we’re uncertain either way, we might as well pick the option that requires less time and money. So when people say “the project is too complex,” what they’re really saying is “prove to me that these features are justified.”
He goes on to talk about the relationship between “unnecessary until proven required” and The Presumption of Innocence, which is widley considered to be an essential right of peoples belonging to a democratic society.
I propose that we adopt “unnecessary until proven required”, which is perhaps also known as YAGNI, as one of the “strength traits” that help ensure the successful evolution of a system.
How to slay this cow? [@lesscode.org]:
[…] Anyway, here’s something IBM/Zend or other members of our community toating around a fair amount of spare cash and resources could do to help the poor hippies out in gaining a bit of acceptance: slay this cow once and for all, formally, by setting up an environment to simulate the kinds of “enterprise class” loads we’re seeing in even the most demanding environments. You can use David’s basic setup or perhaps this one from circa 2000. If, upon being weighed we’re found wanting, we’ll find a way to fix it like we’ve been doing forever. But we would feel more comfortable if the burden of proof was placed appropriately. Our repeated attempts to show the scaling capabilities of LAMP/friends seem destined to be repeatedly deflected by the Enterprise Class Distortion Field. […]
pingback at 12. July 2005
james governor:
in philosophy there is a related concept called Occam’s Razor.
http://en.wikipedia.org/wiki/Occams_razor
comment at 27. July 2005
Маниакальный Веблог » Хранение объектов не в БД:
[…] В общем и целом, я совсем не уверен, что этот подход обязательно себя оправдает. Это именно эксперимент. Но вместе с тем, сама идея мне нравится. Она хорошо вписывается в концепцию новых методов проектирования, когда какая-то структура или функциональность считается “ненужной, пока не доказана ее неоходимость”, а не “необходимой, пока не доказана ее ненужность”. […]
pingback at 13. August 2005
Motherhood and Apple Pie:
[…] So I would like to impress upon you that the languages that dominate the web are not the way they are because we lack the ability to build more complex, sophisticated, flashy tools and languages, they are that way because we assume extra complexity is unnecessary until proven required and we see very little evidence to support the inclusion of the complexities that have been introduced into “enterprise class” software over the past decade. […]
pingback at 11. January 2007