4 ms·

> Don't look into the future. Because you cannot. And you are both naive and arrogant if you believe you can. Deal with what is known now! NO! This mentality

> Don't look into the future. Because you cannot. And you are both naive and arrogant if you believe you can. Deal with what is known now! NO! This mentality is short sighted by definition and leads to stagnation. It may work within large financially healthy companies that aren't trying to rock to the boat. Making assumptions about the future is incredibly important for us to move forward. But with these caveats: 1) Acknowledge that you are taking a risk and that you may be wrong. 2) Validate your assumptions as quickly and as often as you can. 3) Be prepared to change course whenever your assumptions are invalidated. > Less experienced people are generally guided by their beliefs around their own ideas. If the mind is locked onto something it's hard not to thing it's a good idea. Usually in software there is simpler approach. Less experienced people are frequently the driving force behind new ideas precisely because of their belief in it. As experienced people we should be encouraging them to carry forward responsibly instead of projecting our aged and jaded perspectives. > I can go on because I help companies and teams for a living. Honestly, that's a weird way to phrase what you do.

wtetzner 4y ago
I think you and the parent are talking about two different things. Building products that are looking to the future is valuable, if risky. But I believe the parent comment was talking about software abstractions. i.e., don't build abstractions because you might need them later. Instead, build the software in the simplest possible way to solve the problems it needs to handle now. This is because you'll likely be wrong about your assumptions about which abstractions you'll need, and ripping those abstractions out is going to be more expensive than just modifying simple code to do new things.
- 0xFACEFEED 4y ago
  We're talking about the same thing. Perhaps I was just speaking more broadly. > don't build abstractions because you might need them later ... [snip] ... This is because you'll likely be wrong about your assumptions about which abstractions you'll need, and ripping those abstractions out is going to be more expensive than just modifying simple code to do new things. At worst, this is dangerously wrong. At best, it creates a straw man that people can use as a tool to shut down innovative ideas. What you're describing is a very narrow/specific strategy that one might apply at a company. An example would be when a company is doing well financially and you don't need to risk amassing technical debt for some experimental side projects. Just build the MVPs, see what sticks, and only then decide whether or not to commit serious architecture to the problem. If you're designing new systems that need to scale quickly (just one example) then you NEED to place bets on abstractions. A well designed abstraction could save you weeks (even months!) of time when you most need it. I've seen what happens when a successful product is comprised of stitched together MVPs. It's too late for a rewrite and all of that "simple code" is creating a death-by-a-thousand-cuts nightmare. Bad abstractions will always be bad. Bad system design will always be bad. It's an aged/jaded mentality to claim that we should just stop designing systems ahead of time because we suck at it. Not everyone does. Some people are actually very good at it. It's possible to design an abstraction defensively so that it isn't more expensive to rip it out later. Want a concrete example? Payment systems. If I'm writing a billing system then you bet I'm going to abstract away the interface with the payment processor. I would do this irrespective of our plans to expand to other payment processors. It shouldn't even be a debate because there's a way to build that abstraction with minimal overhead to the team. On the other hand I would never blindly introduce an ORM into a system that doesn't need it. That would be a bad abstraction.
  - vinyl7 4y ago
    > A well designed abstraction could save you weeks (even months!) of time when you most need it. Or it could cost you a lot if your guesses are wrong. It goes both ways. It's better to write code the simplest way to do what it needs to do now, but in a way that can be pulled out into a new system/abstraction later in an easy way. This is generally done by writing data-oriented code (focus on what the data is and how it needs to be transformed) rather than object-oriented code.
    - 0xFACEFEED 4y ago
      The problem is that everyone's definition of "simple" and "in a way that can be pulled out" is different. And in any case... just about everything you write is an abstraction to some degree; the question is, where is the line? It's not hard to write abstractions defensively. For example you can limit access to your abstraction to a small and strict interface. What you do behind that interface can be the wild west; as long as you can just lop it off later. > It goes both ways. It does, but the word "simple" is often used in a deceptive way. A cacophony of "simple" systems are actually very complex in aggregate. There are many cases (eg: something is your core business) where you'd want to put a lot of thought into an abstraction ahead of time. You'd then want to validate that abstraction's effectiveness and adjust as you go.
  - danielovichdk 4y ago
    I totally agree on validating ideas but that's IMO not looking in to the future. It's trying to find a fit for something you believe is a good idea. There is a big difference in testing whether something is needed in the near future or you simply stick to your guns and blindly dictate how you believe the future will look like. Your ORM example is good and exactly what i am referring to. Too much abstraction/gold plating due to unknown requirements in the future is perhaps a better way to put what is a problem. And you also say that "If you're designing new systems that need to scale quickly..." - if you know that it will scale quickly then of course you know you need to do certain implementations to cater that. But if you do not know whether it will scale quickly then you are looking into an unknown future - and then you should step back on abstractions.
- danielovichdk 4y ago
  This. Thank you for clarifying

wtetzner 4y ago

I think you and the parent are talking about two different things. Building products that are looking to the future is valuable, if risky. But I believe the parent comment was talking about software abstractions. i.e., don't build abstractions because you might need them later. Instead, build the software in the simplest possible way to solve the problems it needs to handle now. This is because you'll likely be wrong about your assumptions about which abstractions you'll need, and ripping those abstractions out is going to be more expensive than just modifying simple code to do new things.

0xFACEFEED 4y ago
We're talking about the same thing. Perhaps I was just speaking more broadly. > don't build abstractions because you might need them later ... [snip] ... This is because you'll likely be wrong about your assumptions about which abstractions you'll need, and ripping those abstractions out is going to be more expensive than just modifying simple code to do new things. At worst, this is dangerously wrong. At best, it creates a straw man that people can use as a tool to shut down innovative ideas. What you're describing is a very narrow/specific strategy that one might apply at a company. An example would be when a company is doing well financially and you don't need to risk amassing technical debt for some experimental side projects. Just build the MVPs, see what sticks, and only then decide whether or not to commit serious architecture to the problem. If you're designing new systems that need to scale quickly (just one example) then you NEED to place bets on abstractions. A well designed abstraction could save you weeks (even months!) of time when you most need it. I've seen what happens when a successful product is comprised of stitched together MVPs. It's too late for a rewrite and all of that "simple code" is creating a death-by-a-thousand-cuts nightmare. Bad abstractions will always be bad. Bad system design will always be bad. It's an aged/jaded mentality to claim that we should just stop designing systems ahead of time because we suck at it. Not everyone does. Some people are actually very good at it. It's possible to design an abstraction defensively so that it isn't more expensive to rip it out later. Want a concrete example? Payment systems. If I'm writing a billing system then you bet I'm going to abstract away the interface with the payment processor. I would do this irrespective of our plans to expand to other payment processors. It shouldn't even be a debate because there's a way to build that abstraction with minimal overhead to the team. On the other hand I would never blindly introduce an ORM into a system that doesn't need it. That would be a bad abstraction.
- vinyl7 4y ago
  > A well designed abstraction could save you weeks (even months!) of time when you most need it. Or it could cost you a lot if your guesses are wrong. It goes both ways. It's better to write code the simplest way to do what it needs to do now, but in a way that can be pulled out into a new system/abstraction later in an easy way. This is generally done by writing data-oriented code (focus on what the data is and how it needs to be transformed) rather than object-oriented code.
  - 0xFACEFEED 4y ago
    The problem is that everyone's definition of "simple" and "in a way that can be pulled out" is different. And in any case... just about everything you write is an abstraction to some degree; the question is, where is the line? It's not hard to write abstractions defensively. For example you can limit access to your abstraction to a small and strict interface. What you do behind that interface can be the wild west; as long as you can just lop it off later. > It goes both ways. It does, but the word "simple" is often used in a deceptive way. A cacophony of "simple" systems are actually very complex in aggregate. There are many cases (eg: something is your core business) where you'd want to put a lot of thought into an abstraction ahead of time. You'd then want to validate that abstraction's effectiveness and adjust as you go.
- danielovichdk 4y ago
  I totally agree on validating ideas but that's IMO not looking in to the future. It's trying to find a fit for something you believe is a good idea. There is a big difference in testing whether something is needed in the near future or you simply stick to your guns and blindly dictate how you believe the future will look like. Your ORM example is good and exactly what i am referring to. Too much abstraction/gold plating due to unknown requirements in the future is perhaps a better way to put what is a problem. And you also say that "If you're designing new systems that need to scale quickly..." - if you know that it will scale quickly then of course you know you need to do certain implementations to cater that. But if you do not know whether it will scale quickly then you are looking into an unknown future - and then you should step back on abstractions.
danielovichdk 4y ago
This. Thank you for clarifying