I have been aware of, and even talking about, YAGNI (“You ain’t going to need it”), and the dangers of “future-proofing” for a long while. But not until recently have I actually applied this principle in earnest.
Trying to understand what took me so long, I took note of what makes other developers hesitant to apply this principle.
When I try to get others to practise YAGNI, I find the same reluctance that I myself have shown.
When I say to a team member (or to my younger self) “you ain’t going to need it”, the answer is always “yes, you’re probably right. But what if…??”.
And there’s no good way to answer that. I can’t prove that, in every possible future universe, we will never need this code.
Thus YAGNI fails to convince, and the redundant code stays.
I think I’ve been able to find a better argument, though.
My solution has been to play along with this thought experiment.
“OK, so what if we don’t put that ‘future-proof’ code there right now?
And suppose we do find out, in the future, that we do need to make that change?
Would that be such a disaster?
Or, if that happens, we can then make the change that you’re proposing now, right?
And even better – at that point, we’ll have more information and ability to make the right sort of change.”
I’ve had much better success with this line of arguing. We realise that future us are better equipped to deal with this change then present us.
We “just” need to believe in ourselves.
..About that “just”
So why don’t we, by default, believe in future us?
Why don’t we believe that future us can make that change just as well as present us?
I actually already alluded to this in a previous post, about being scared of changing code:
Loss of context and lack of confidence, are the main issues here.
Context
We know that at this point in time, when we’re well-versed with this part of the code, we can see a good (future) solution.
However, we’re not confident that we’ll see it in the future, when we maybe don’t remember everything about this area of the codebase.
It’s easy to see where this sentiment comes from. Many times when we read past code, we’re not confident that we 100% understand it. So why should the code we’re writing now be any different?
It’s taken me many years to have enough self confidence to counter that.
No, I am competent enough that when I do come back to this in the future, I will understand it well enough.
And I’ll make sure of that by leaving some clues for myself – clear names, easy to understand design, descriptive tests, etc.
(An important side point here is about continuity of knowledge.
The person, or team, that authored the original code, would only need a reminder of what it does, and how.
But a different person / team will have much much lower confidence in understanding the code.
The amount of clues – good names, comments, tests etc. would have to be even higher for them.)
Confidence
By this I don’t mean self-confidence, but the confidence in our changes. That we won’t be breaking anything.
For that, a good test suite, good monitoring and remediation tools are required.
But especially needed is a high degree of psychological safety. The confidence that, if we do end up breaking something, we won’t be punished for it.
Conclusion
Saying “YAGNI” is often not convincing enough. Many people’s response to that is that “Well, we can’t know that for certain. And when we will ‘need it’, then it’ll be too late!”.
I propose a more convincing argument – “We Can Always Change It Later”, or “WCACIL” (pronounced… er… however you want to pronounce it).
This argument needs to be supported by a framework that makes future change less scary:
Tests, documentation, simple design, and a safe environment.
And also, maybe a prod from more experienced team members who’ve done it before.
The Useless Dev blog 