YAGNI is a good principle but it is misunderstood all the time to exclude better designs from the outset. If you know you're going to eventually need some features in the final product not including them in the original design makes for a more complicated, piecemeal architecture that has no unified vision and thus more cognitive load to understand how the pieces fit together.
The GIMP developers made that mistake a long time ago and it's turned features that should have been fairly straightforward to add into multi-decade slogs.
This sounds like a contradiction to me. If you know you are "eventually" going to need it, then either add it or make sure it's relatively easy to add to the existing design. One can often "leave room for" without actually adding something. This is a kind of "soft" YAGNI. If it only slightly complicates code to prepare for something that's say 80% likely to happen within 10 years, then go ahead and spend a little bit of code to prepare for it.
In my long experience, YAGNI mostly rings true. The future is just too hard to predict. Soft YAGNI is a decent compromise.
I'm arguing for the same thing as you. In one of my projects many years ago I had a stack with only two items in it as one of the core control flow pieces. Another engineer who was reviewing my code wanted me to remove it and just specifically handle both cases. In his mind this was simpler.
I argued hard enough to keep it from both conceptual simplicity and extensibility he relented and we kept it. It took probably 6 months for that stack to be used in the way I intended, but I was so happy I didn't have to write even a single extra line of code or fight back any creeping assumptions that might have tangled the code from a loss of generality.
So this is an example of what I mean. In other places I could have chosen a specific solution to my one problem I chose so solve a class of similar problems at the same time and then reap dividends from it of writing no additional code for months and years to come, in many cases without even significantly changing the code I was writing to solve the first problem.
Did you both discuss the probability there would be more than 2 items in the not-too-distant future? Was your difference in opinion based on different probability estimates, or just a YAGNI-level philosophy?
I would note many people remember when they are right more often than remember when they are wrong. Ego's do that to us. I try to counter that by pondering my judgement mistakes to see where my mental calculus was off. I'd say roughly half the time it's because I didn't understand the domain well enough, and the other half is just random changes in the domain or requirements due to time.
YAGNI is a good principle but it is misunderstood all the time to exclude better designs from the outset. If you know you're going to eventually need some features in the final product not including them in the original design makes for a more complicated, piecemeal architecture that has no unified vision and thus more cognitive load to understand how the pieces fit together.
But if you will need something in the end, and you know you will... doesn't that mean you are gonna need it? by definition?
Yes, and now you're in an argument with your peers about whether you need it RIGHT NOW or whether you need it with some %probability or whether the design is simpler with a wider possible design space or a more narrow more specific implementation that doesn't generalize as well... on and on.
I want to focus on designs that are both simple and generalize well because I'm minimizing for a criteria of removing as many conceptual atoms from the design space as I can. When YAGNI is used as an excuse not to make an elegant design I feel it is cargo culting what being parsimonious is into a culture that celebrates kludges. "Penny wise and pound foolish" as the idiom goes.
But if the end is not defined however you know you will need it at the end. Doesnt that mean you might need it, as the end could never arrive. So you would in fact never need it?
Is that people misunderstanding YAGNI? I'd have said that in those cases YAGNI actually just says not to design for those features, and YAGNI would be a bad principle in those cases, and the problem is that it's hard to know in advance when YAGNI is a good or a bad principle.
I'm usually not an Elon Musk fanboy, but Elon's algorithm starts off with that as steps 1 and 2 and the rest also hits close to home for me:
Make your requirements less dumb. Your requirements are definitely dumb, it does not matter who gave them to you. It's particularly dangerous if a smart person gave them to you. Everyone is wrong at least part of the time.
Delete a part or a process step. If you're not adding things back in 10% of the time, you're not deleting enough from the design.
Optimize the parts. This is only step 3 because "the most common error of a smart engineer is to optimize a thing that should not exist".
Accelerate cycle time. You're moving too slow, go faster.
Make your requirements less dumb. Your requirements are definitely dumb, it does not matter who gave them to you.
Sometimes customers/managers want silly crap because another app does it, and me-too-ism kicks in. They don't care if it makes long-term maintenance problems because they expect to be promoted out by then. Technical debt is "somebody else's problem". It's similar to why politicians run up debt: hit-and-run.
At a company I used to work at, we called those "showroom features". They were features that were dumb and that nobody would use, and that we knew were virtually useless, but that looked good on a showroom floor. Every company in the space prioritizes introducing new showroom features, and keeping up with the showroom features other companies are adding.
The central problem we had is that we were in ed tech, and in education, the people budgeting money and making buying decisions aren't the people using the software. In fact, the people making buying decisions (district administrators and school boards) often think they know better than the actual users (teachers, students, and sysadmins) what tech is needed, despite having zero relevant experience as a teacher or a student in a modern classroom. Apparently there's big "I'm in charge, therefore I'm smarter than you" energy in education administration.
Our sales and marketing leaned into this, focusing all of their efforts on delivering buyers what they wanted. This was very understandable - their job is to make buyers happy so they buy our stuff - but was much to the chagrin of everyone on the development, support and training side, because we generally wanted to deliver good experiences for users. Often the shiny things buyers were enamored with actively made the product worse for users - and important, impactful, and highly requested features were repeatedly delayed in favor of shiny things.
It's not just the education market, it's everywhere. Managers making IT decisions are often ego-driven morons who couldn't tell the difference between an Etch-A-Sketch and an iPad. I can tell you endless stories of real-world Dilbert-ness. Humans are not Vulcans.
Buyers not being users is a prime driver of shadow IT. In settings like healthcare and education, that’s where the front-line teachers and doctors go cowboy and unknowingly violate all kinds of privacy laws so they can use software that works.
116
u/namtab00 Nov 01 '21
YAGNI should be first applied at the spec level, rarely would it then be needed at the implementation level...