I've seen complex atrocities created by blindly following KISS and YAGNI. It just takes a non-obvious path, and a few months of code and requirements evolution.
Blindly following anything -- especially nuanced, process-driven ideological frameworks -- is a recipe for a disaster.
KISS and YAGNI are examples of processes that require the person who is using them to actually think through the implications within the context of the problem being solved.
KISS and YAGNI did not cause the atrocities that you've seen. Those complex beasts of code existed because the team fundamentally didn't understand what they were doing.
It's like "agile" software development. Just declaring that you're following an agile methodology and scheduling stand-ups does not mean that you're going to be successful. It takes someone (and usually, many someones) who understand how to iteratively design and develop to be successful.
> It just takes a non-obvious path, and a few months of code and requirements evolution.
Can you expand on this comment? I'm interested in understanding what you mean by "non-obvious path".
> Blindly following anything -- especially nuanced, process-driven ideological frameworks -- is a recipe for a disaster.
Yep. That's the point, that's why I pointed it was blind.
Many people blindly follow and impose that kind of ideology. Most people that even mention YAGNI outside of a classroom are blind followers (for DRY things are more diverse).
By non-obvious path I mean things (requirement, underlining systems, user base size) changing in a way that was not unquestionably and blatantly obvious.
> By non-obvious path I mean things (requirement, underlining systems, user base size) changing in a way that was not unquestionably and blatantly obvious.
I can't agree with you more. Thank you for the follow-up.
If "Keep It Simple Stupid" causes one to make something complex, they have failed to keep it simple, and can't blame the principle for their failure to adhere to it.
Marcosdumay did not state that "complexity" was the problem, but "requirements evolution".
Following KISS and YAGNI means you hard code lots of assumptions. When the requirements change, it means you have to fix all those subtle hard-coded assumptions everywhere and that is usually hard.
Also, if a single concept pops up as something that's needed once every month for six months, it's way easier to have that get re-implemented six times rather than abstracted.
Blindly following anything -- especially nuanced, process-driven ideological frameworks -- is a recipe for a disaster.
KISS and YAGNI are examples of processes that require the person who is using them to actually think through the implications within the context of the problem being solved.
KISS and YAGNI did not cause the atrocities that you've seen. Those complex beasts of code existed because the team fundamentally didn't understand what they were doing.
It's like "agile" software development. Just declaring that you're following an agile methodology and scheduling stand-ups does not mean that you're going to be successful. It takes someone (and usually, many someones) who understand how to iteratively design and develop to be successful.
> It just takes a non-obvious path, and a few months of code and requirements evolution.
Can you expand on this comment? I'm interested in understanding what you mean by "non-obvious path".