YAGNI! You Aren't Gonna Need It. It's a phrase I've been broadcasting a lot lately. It sparked lively debates within our team. My observation is that most software engineers have a remarkable inclination to do the opposite.
Here, I'll explain why I believe YAGNI is an essential Agile ingredient and show how Elon Musk uses the underlying principle at SpaceX.
An Agile Principle
YAGNI is a principle from Extreme Programming (XP) that says a capability we think (assume) is needed in the future shouldn't be developed now. It's also known as Simple Design.
Five of the seventeen authors of the Agile Manifesto were Extreme Programmers. Its apparent inclusion in the 12 Principles of the Agile Manifesto is, therefore, no surprise.
Principle #10:
'Simplicity—the art of maximizing the amount of work not done—is essential'.
YAGNI maximises the amount of work not done by minimising the work on hypotheticals.
YAGNI prevents waste
Why would we want to maximise the amount of work not done? Because we don't want to produce waste.
Lean manufacturing defines waste as anything that doesn't add value and overproduction as a type of waste. Value is whatever the customer desires. We'd overproduce if we develop more than needed to meet our customer’s known desires.
There are many parallels between Agile and Lean. Kent Beck mentioned how reading Toyota Production System by Taiichi Ohno influenced his thinking and how he explained XP (before he co-authored the Agile Manifesto). He shared the following:
Just thinking of overproduction as a problem rocked my world!
If we add unnecessary functionality for our current requirements just 'in case' it's needed in the future, we're not adding any value now. If the hypothetical never happens (likely), the time & effort spent on it would've been wasted on overproduction.
Looking elsewhere
Doctors follow a YAGNI-ish practice. They only prescribe medicine for problems they know their patients have. Imagine the problems if doctors prescribed unnecessary medication 'in case' their patients have hypothetical complications in the future. Let's be more like doctors and only write specifications & code (prescriptions) for our customers' known needs, shall we?
It's not rocket science. Producing more than needed will cost the customer more. Speaking of rocket science, let's consider how Elon Musk uses the underlying principle at SpaceX.
Elon Musk's 5-step process
Elon Musk described his 5-step engineering process in an interview Everyday Astronaut had with him at SpaceX's Starbase. His second step is a principle that says you should try to delete a part or process step.
The following are quotes from the interview.
He recognises the in-case inclination of engineers:
'The bias tends to be very strongly towards let's add this part or process step in case we need it. But you can basically make in-case arguments for so many things...'
He gave an example of how they applied it to their rockets:
'So that's why the grid fins, for example, don't fold down because that's a whole extra mechanism that we don't need . . .
. . . But in any case it's a thing we could add later . . .
. . . But it followed the principle of, like, delete the part delete the process.'
I felt like I was in good company when I watched the interview. Elon Musk's principle is the same as YAGNI! With YAGNI, we prevent (delete) parts we don't need for our current requirements. If the part we prevented becomes a need in the future, we could simply add it then.
I love how he put the following:
'Possibly, the most common error of a smart engineer is to optimize a thing that should not exist.'
Genius!
Conclusion
YAGNI. Simple Design. Elon Musk's engineering principle. Think of it as the art of minimising overproduction. Let's strive to launch more by doing less!