LOVE this explanation! Mostly because, although I've believed YAGNI since I first read it (something like 25 years ago) and often cited it, I also often ignored it internally because I just love crafting elegant designs and patterns. The endorphin hit I get from that is just too tempting to resist sometimes. BUT... this explanation and metaphor will (hopefully) help me resist the internal temptation AND help sell it externally when I need to.
I also really like the economics analogies you make when explaining software development topics. They make me feel like I actually understand economics, pricing, and such (which I barely do).
I am _so_ guilty of building speculative structure. Or approving the building of it. Last time I did it, when the consequences arrived I should have been fired, it was so bad. But because bad engineering decisions often seem diffuse to non-technical executives, I kept my job. I always felt like I was living on borrowed time after that. Lesson deeply learned.
This is very well stated. I always find it difficult to tease apart the strands of thought that get intertwined in a pithy phrase or idea, so I found the piece quite helpful.
There's at least one more factor to recommend YAGNI: most humans don't really know whether they need a feature until they've had practical, hands-on time using that feature. In custom/bespoke software development, I've built many "must have" features that the customer didn't actually use after a few days or weeks. The fantasy and the reality didn't match.
In that case, building structure to perfectly support an unused feature, or set of features, is like a bridge to nowhere.
You are taking me back to the talk you and Hakan Erdogmus gave at that first XP Universe called "XP For Capitalists". I have referred back to that many times of the years, but never in this context. Thanks for expanding my toolbox!
You've spoken in the past about "Bundles of Options" and the value of optionality. I found that piece moving, both as an engineer and (bad) trader, and was curious how you reconcile the concepts presented in that piece with those in this one? Unless I'm mistaken (I often am), they seem to be at conflict? Or is it simply that "options" in the profitable sense are those that are known to be used, or variants of revenue-driving product code (i.e., build it all when you need it) vs. "options" in the sense of trying to predict what will drive revenue before you know so you'll have all hypothetical ground covered?
I think I answered my own quesiton, but would love to hear your take.
Great Post! The Genie absolutely encourages YAGN by being an always on partner more than willing to discuss and argue about every feature seemly verifying the bloated design. YAGN architecture and design are even worse than the code! Of course the coding by human or machine will be overhelmed by the YAGN design.
LOVE this explanation! Mostly because, although I've believed YAGNI since I first read it (something like 25 years ago) and often cited it, I also often ignored it internally because I just love crafting elegant designs and patterns. The endorphin hit I get from that is just too tempting to resist sometimes. BUT... this explanation and metaphor will (hopefully) help me resist the internal temptation AND help sell it externally when I need to.
I also really like the economics analogies you make when explaining software development topics. They make me feel like I actually understand economics, pricing, and such (which I barely do).
Incoming! I came up with a new one yesterday.
I am _so_ guilty of building speculative structure. Or approving the building of it. Last time I did it, when the consequences arrived I should have been fired, it was so bad. But because bad engineering decisions often seem diffuse to non-technical executives, I kept my job. I always felt like I was living on borrowed time after that. Lesson deeply learned.
The desire to exhibit our cleverness can be overwhelming.
This is very well stated. I always find it difficult to tease apart the strands of thought that get intertwined in a pithy phrase or idea, so I found the piece quite helpful.
There's at least one more factor to recommend YAGNI: most humans don't really know whether they need a feature until they've had practical, hands-on time using that feature. In custom/bespoke software development, I've built many "must have" features that the customer didn't actually use after a few days or weeks. The fantasy and the reality didn't match.
In that case, building structure to perfectly support an unused feature, or set of features, is like a bridge to nowhere.
You are taking me back to the talk you and Hakan Erdogmus gave at that first XP Universe called "XP For Capitalists". I have referred back to that many times of the years, but never in this context. Thanks for expanding my toolbox!
You've spoken in the past about "Bundles of Options" and the value of optionality. I found that piece moving, both as an engineer and (bad) trader, and was curious how you reconcile the concepts presented in that piece with those in this one? Unless I'm mistaken (I often am), they seem to be at conflict? Or is it simply that "options" in the profitable sense are those that are known to be used, or variants of revenue-driving product code (i.e., build it all when you need it) vs. "options" in the sense of trying to predict what will drive revenue before you know so you'll have all hypothetical ground covered?
I think I answered my own quesiton, but would love to hear your take.
Great Post! The Genie absolutely encourages YAGN by being an always on partner more than willing to discuss and argue about every feature seemly verifying the bloated design. YAGN architecture and design are even worse than the code! Of course the coding by human or machine will be overhelmed by the YAGN design.
Great article Kent! I love your content and I learn new things with it.