Pretty good attempt to consolidate the nuances of design decision-making. I like what the author is trying to do. I would have enjoyed a little discussion of unpredictable unknown-unknowns from this perspective.
I think the article is a convoluted way of saying "use your judgement". The cost of adopting certain design, per the article, is not a real number, it is an estimate. The probability of needing a feature, P2, per the article, is also not a real number but an estimate.
What's so hard to estimate in software world is because the shear amounts of unknown. An abstraction leaking library, a not-fitting-exactly-your-use-case SaaS, ever changing standards, end-of-life of mission critical component, no-easy-fix vulnerability, emotional stress from team member, a dying cat, a never stop talking non-engineering colleague, there are more than "code" in software. Be prepared for change
This is where the experience of Solution Architects comes in, the whole design decisions gets a whole more complex once you start throwing in infrastructure choices and percieved future options.
As a genernal rule I find a large percentage of Solutioning follows the latest new framework.
Going through past designs for many projects over many years and looking at the key design decisions is fascinating - it's almost like being a an Archaeologist looking at latest 'in fashion' technology at that time
This is an appealing take, but I'm not convinced it's right. In over 10 years of programming work I've literally never regretted making a YAGNI choice (even in the cases where I did eventually have to go back and do the thing), and I've often regretted doing something overly complex up front. Maybe there is actually a substitute for judgement on this particular question.
I am the complete opposite. I hardly ever regret adding things that I later decide to remove, and I frequently regret dismissing the potential need for something that would have been much easier to add (or at least to lay the groundwork for) at the start.
If you add something and later decide you don’t need it, you can remove it. If you added it badly, with loose couplings etc such that it is now painful to remove or replace, well there’s your problem. Flexible, modular patterns are the better solution for that, not a blanket stand against adding stuff.
> I frequently regret dismissing the potential need for something that would have been much easier to add (or at least to lay the groundwork for) at the start.
> If you add something and later decide you don’t need it, you can remove it. If you added it badly, with loose couplings etc such that it is now painful to remove or replace, well there’s your problem.
I don't understand this logic at all. If it's not something that needs to be deeply intertwined with other logic, then it's no trouble to add it later. If it does need to be deeply coupled to the rest of the system, then ipso facto it'll be painful to remove.
Flexibility and modularity are no substitute for simplicity; indeed it's often much harder to add something to a modular system if the module boundaries aren't in exactly the right place (and they usually aren't).
Maybe you often add too many things and get into a complexity nightmare that way. I often err too far the other way, skipping working on boring-but-important groundwork features, I try to press on without them, making life too hard for myself. I tend to justify this avoidance as I’m keeping the system ‘simple’ but then I end up stupidly creating more complexity to work around not having the sensible/useful thing I’ve been avoiding adding.
So for you, YAGNI is a useful corrective notion to try to keep in mind. For me it’s playing to my worst instincts. This is the case for all one-sided and unbounded advice like YAGNI. It is useful for people who need to hear it and harmful for those who don’t.
I prefer the idea of “everything should be as simple as possible, but no simpler”. The last bit is crucial for me and is missing from “YAGNI”.
The example he uses isn't the best though. Unless your product is about identity or have other special circumstances, you should absolutely not implement your own login system. It's a lot more complicated than what the article suggest: security, _proper_ hashing, forgot your password, change password, change email, password strength, MFA, privacy, compliance, social logins are just a few things/flows coming to my mind that are standards today. Implementing these instead of focusing on the relevant features of the application is very rarely the right decision.
Depending on what you're doing, user accounts seem like a rather fundamental thing to be transferring control of to some third party that could, I don't know, decide they only like green while you're orange.
Both options have risks, in 90% of the cases, the risk you pointed out is smaller then the risk from the lost opportunity cost (working on something not relevant for the service), insecure implementation, sub-optimal UI, etc.
12 comments
[ 3.1 ms ] story [ 40.3 ms ] threadWhat's so hard to estimate in software world is because the shear amounts of unknown. An abstraction leaking library, a not-fitting-exactly-your-use-case SaaS, ever changing standards, end-of-life of mission critical component, no-easy-fix vulnerability, emotional stress from team member, a dying cat, a never stop talking non-engineering colleague, there are more than "code" in software. Be prepared for change
This is where the experience of Solution Architects comes in, the whole design decisions gets a whole more complex once you start throwing in infrastructure choices and percieved future options.
As a genernal rule I find a large percentage of Solutioning follows the latest new framework.
Going through past designs for many projects over many years and looking at the key design decisions is fascinating - it's almost like being a an Archaeologist looking at latest 'in fashion' technology at that time
Is it "there is no substitute for judgement"??
If you add something and later decide you don’t need it, you can remove it. If you added it badly, with loose couplings etc such that it is now painful to remove or replace, well there’s your problem. Flexible, modular patterns are the better solution for that, not a blanket stand against adding stuff.
> If you add something and later decide you don’t need it, you can remove it. If you added it badly, with loose couplings etc such that it is now painful to remove or replace, well there’s your problem.
I don't understand this logic at all. If it's not something that needs to be deeply intertwined with other logic, then it's no trouble to add it later. If it does need to be deeply coupled to the rest of the system, then ipso facto it'll be painful to remove.
Flexibility and modularity are no substitute for simplicity; indeed it's often much harder to add something to a modular system if the module boundaries aren't in exactly the right place (and they usually aren't).
So for you, YAGNI is a useful corrective notion to try to keep in mind. For me it’s playing to my worst instincts. This is the case for all one-sided and unbounded advice like YAGNI. It is useful for people who need to hear it and harmful for those who don’t.
I prefer the idea of “everything should be as simple as possible, but no simpler”. The last bit is crucial for me and is missing from “YAGNI”.