3 ms·

This seems to directly contradict YAGNI. I find that when I "write for the future", I over-engineer things and they get messy and bloated.

0xFACEFEED 6y ago
I find the opposite. This topic is fascinating to me actually. I'm a system oriented thinker. I don't know how I do it, but I'm able to design forward-thinking systems in my head... really well. Like large complex systems. I've since validated this with retrospectives (checking my past decisions, how they worked out, and how they compare to others). The systems turn out to be fairly elegant in their simplicity and ability to scale. So what's going on here? I think maybe the answer is pretty simple. Some people are good at building large abstract systems and some people aren't. In fact one thing I'm bad at is narrowly focusing on problems. My solutions are always good enough but not great there. Oversimplified example: if you were to ask me to build a highly performant sorting algorithm I'd probably just give you an okay solution. But if you were to ask me to design a distributed system that runs these sorting algorithms (where the algorithms itself is a black box; implemented already) I'd do really well!
breischl 6y ago
I took his meaning as "assume better hardware will be available in the future", which is not what you seem to mean, and may not be as true these days anyway. That said, when I've seen people over-engineer things (and maybe this isn't your problem, it's just what I've seen most) it's usually because instead of solving the problem in front of them, they created a flexible framework to solve a class of problems including the one in front of them. And it usually fails because they don't actually know what other problems they'll encounter - they guess and get it wrong. So their framework is flexible on Dimension X, but they actually need it to be flexible on Dimension Y. The best advice I read on this was to never build a framework until you have at least 3 examples of the problem. Once you've got 3 examples, you have a good feel for which ways it needs to be flexible. I would add that you should also make sure you'll eventually have more than 3, because if 3 is the total number of concrete examples you still don't need a framework. Also, it's entirely possible some smart guy/gal can give you those 3 examples before you even start building. A good product person can do that. If you have that, and they're pretty sure you'll actually get there, then go ahead and build it. Difficulty of changing it in the future also plays into this, but I've typed too much already. :)

0xFACEFEED 6y ago

I find the opposite. This topic is fascinating to me actually. I'm a system oriented thinker. I don't know how I do it, but I'm able to design forward-thinking systems in my head... really well. Like large complex systems. I've since validated this with retrospectives (checking my past decisions, how they worked out, and how they compare to others). The systems turn out to be fairly elegant in their simplicity and ability to scale. So what's going on here? I think maybe the answer is pretty simple. Some people are good at building large abstract systems and some people aren't. In fact one thing I'm bad at is narrowly focusing on problems. My solutions are always good enough but not great there. Oversimplified example: if you were to ask me to build a highly performant sorting algorithm I'd probably just give you an okay solution. But if you were to ask me to design a distributed system that runs these sorting algorithms (where the algorithms itself is a black box; implemented already) I'd do really well!

breischl 6y ago

I took his meaning as "assume better hardware will be available in the future", which is not what you seem to mean, and may not be as true these days anyway. That said, when I've seen people over-engineer things (and maybe this isn't your problem, it's just what I've seen most) it's usually because instead of solving the problem in front of them, they created a flexible framework to solve a class of problems including the one in front of them. And it usually fails because they don't actually know what other problems they'll encounter - they guess and get it wrong. So their framework is flexible on Dimension X, but they actually need it to be flexible on Dimension Y. The best advice I read on this was to never build a framework until you have at least 3 examples of the problem. Once you've got 3 examples, you have a good feel for which ways it needs to be flexible. I would add that you should also make sure you'll eventually have more than 3, because if 3 is the total number of concrete examples you still don't need a framework. Also, it's entirely possible some smart guy/gal can give you those 3 examples before you even start building. A good product person can do that. If you have that, and they're pretty sure you'll actually get there, then go ahead and build it. Difficulty of changing it in the future also plays into this, but I've typed too much already. :)