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 find YAGNI mostly wrongly applied - and I like your explanation which grounds in optionality and NPV - that's the right way to look at it.
I've however been on the receiving end of YAGNI that decreases optionality. Unbounded YAGNI can only operate in environments where the decision to refactor is a fully technical one. In an environment where pushing to ship features against unrealistic build expectations is the norm - refactoring is discouraged and technical debt explodes. Eventually you are in a situation where you can't build something that needs sufficient optionality without paying back massive tech debt interest - and so the feature can't pay for itself due to the amount of interest attached to it.
I worry that your post doesn't address this failure mode? I think keeping your options always open is only ever the optimal choice when cost of refactor is zero - when cost of refactor is large, you should have sufficient foresight to be cost optimal.
I’ve seen that. I’ve also seen “you are gonna need it” wrongly applied. The question is not which is worse, the question is whether those making structure decisions ever thought carefully about when to make those decisions. If someone thinks about when and decides now, that works for me (not that my opinion matters).
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.
NPV isn't defined anywhere. It's one of your two core takeaways and it's not defined =/
I asked chatGPT and got "Net Present Value" saying it's a finance concept. Your post taught me something, and the finance analogies are helpful and insightful. But along with my other message, the content is quite hard to get through relative to its length and message.
... and taking into account that code outlives its author. Speculative structure is always a bet placed on someone else's future. and almost always it's the thing that hinders the actual features from growing in the first place.
No surgeon leaves instruments inside a body for future convenience. No civil engineer leaves rebar stubs poking out of a bridge "in case we extend it." The speculative structure that software normalizes would be malpractice in every other engineering discipline.
“The power of unmanifested code… as long as it isn’t written it can be anything at any time - it has infinite potential. The moment you write it, it comes alive but also becomes a victim of the rules that shaped it…”
That’s what your post left me thinking about. I love your mind and the places it takes mine.
I don't get your argument, probably because I'm thick or more likely at 73 not enough experience. Mech eng was my thing. You opened up with you saying you won't need it and your colleague wanting to implement. So in this situation how do you decide who is right and who is wrong?
Another thing, if all this falls within the monthly pay period how do you decide that a cost is being paid forward because the pay check arrives at a certain date regardless.
Although I do disagree about the genie cost, they're along way from being perfect but in my opninon they never will be. If yo run your genie now rather than later what's the big deal., if the decision to implement is correct.
I apologise because I'm confused it's been 15C above normal for the last four days and I'm knacj=kered.
Kindest regards and Keep on truckin. Confuse I may be but I'm still learning.
When doing software, we need to find abstractions and patterns. This is super helpful if you need 5 of a thing. It gets in the way if you need one of a thing. When you write the first one, you don't yet know if you have a generalizable pattern. Junior devs will just write the thing. Senior devs will immediately write an abstract framework. Staff level devs learn better judgement about when to build a framework and when to do a one-off.
For analogy, woodworkers sometimes build a jig and sometimes just use clamps. I expect more experienced woodworkers would better know when to make the jig is worth the effort.
What about the opposite?! When the genie follows to the dot and justifies its decisions with YAGNI, and turns everything in a very simplistic implementation. I know I'm going to need it, it is literally on the following ticket, so create a reusable component now! Or maybe the scenario is that I'm setting up the project structure and the genie replies to me: yagni (and indeed the first ticket has only one class but I know more are coming!) What to do then?
I know the answer is the refactoring discipline, wait for the next ticket, refactor to adhere to the new reality and then implement (or implement and then refactor before closing when the pattern emerges) but sometimes is so hard.
This resonates with me. I am always a victim of pre optimizing and designing. Seeing it worded this way really helps internalize that this is a real cost, and now explained in a domain that is all about costs!
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!
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.
AI changed the economics of implementation, not the economics of maintenance. Code is cheaper to produce, but every design decision still accumulates cognitive load, testing effort, documentation, reviews, and future migration costs.
The desire to exhibit our cleverness can be overwhelming.
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 find YAGNI mostly wrongly applied - and I like your explanation which grounds in optionality and NPV - that's the right way to look at it.
I've however been on the receiving end of YAGNI that decreases optionality. Unbounded YAGNI can only operate in environments where the decision to refactor is a fully technical one. In an environment where pushing to ship features against unrealistic build expectations is the norm - refactoring is discouraged and technical debt explodes. Eventually you are in a situation where you can't build something that needs sufficient optionality without paying back massive tech debt interest - and so the feature can't pay for itself due to the amount of interest attached to it.
I worry that your post doesn't address this failure mode? I think keeping your options always open is only ever the optimal choice when cost of refactor is zero - when cost of refactor is large, you should have sufficient foresight to be cost optimal.
I’ve seen that. I’ve also seen “you are gonna need it” wrongly applied. The question is not which is worse, the question is whether those making structure decisions ever thought carefully about when to make those decisions. If someone thinks about when and decides now, that works for me (not that my opinion matters).
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.
Thanks for the insight, Kent.
I might call this principle ION:
Implement on need.
NPV isn't defined anywhere. It's one of your two core takeaways and it's not defined =/
I asked chatGPT and got "Net Present Value" saying it's a finance concept. Your post taught me something, and the finance analogies are helpful and insightful. But along with my other message, the content is quite hard to get through relative to its length and message.
... and taking into account that code outlives its author. Speculative structure is always a bet placed on someone else's future. and almost always it's the thing that hinders the actual features from growing in the first place.
No surgeon leaves instruments inside a body for future convenience. No civil engineer leaves rebar stubs poking out of a bridge "in case we extend it." The speculative structure that software normalizes would be malpractice in every other engineering discipline.
YAGNI is for other people's code.
My code gets the You Are Gonna Love This treatment.
“The power of unmanifested code… as long as it isn’t written it can be anything at any time - it has infinite potential. The moment you write it, it comes alive but also becomes a victim of the rules that shaped it…”
That’s what your post left me thinking about. I love your mind and the places it takes mine.
Hi Kent hope you're hanging in there.
I don't get your argument, probably because I'm thick or more likely at 73 not enough experience. Mech eng was my thing. You opened up with you saying you won't need it and your colleague wanting to implement. So in this situation how do you decide who is right and who is wrong?
Another thing, if all this falls within the monthly pay period how do you decide that a cost is being paid forward because the pay check arrives at a certain date regardless.
Although I do disagree about the genie cost, they're along way from being perfect but in my opninon they never will be. If yo run your genie now rather than later what's the big deal., if the decision to implement is correct.
I apologise because I'm confused it's been 15C above normal for the last four days and I'm knacj=kered.
Kindest regards and Keep on truckin. Confuse I may be but I'm still learning.
When doing software, we need to find abstractions and patterns. This is super helpful if you need 5 of a thing. It gets in the way if you need one of a thing. When you write the first one, you don't yet know if you have a generalizable pattern. Junior devs will just write the thing. Senior devs will immediately write an abstract framework. Staff level devs learn better judgement about when to build a framework and when to do a one-off.
For analogy, woodworkers sometimes build a jig and sometimes just use clamps. I expect more experienced woodworkers would better know when to make the jig is worth the effort.
What about the opposite?! When the genie follows to the dot and justifies its decisions with YAGNI, and turns everything in a very simplistic implementation. I know I'm going to need it, it is literally on the following ticket, so create a reusable component now! Or maybe the scenario is that I'm setting up the project structure and the genie replies to me: yagni (and indeed the first ticket has only one class but I know more are coming!) What to do then?
I know the answer is the refactoring discipline, wait for the next ticket, refactor to adhere to the new reality and then implement (or implement and then refactor before closing when the pattern emerges) but sometimes is so hard.
If it was easy, regular people could do it 😜
This resonates with me. I am always a victim of pre optimizing and designing. Seeing it worded this way really helps internalize that this is a real cost, and now explained in a domain that is all about costs!
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!
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.
AI changed the economics of implementation, not the economics of maintenance. Code is cheaper to produce, but every design decision still accumulates cognitive load, testing effort, documentation, reviews, and future migration costs.