5 ms·

I will tell you this. It's based on my 20+ years, 50 different teams and many hundreds, perhaps thousands of encounters with software developers. It's almost

I will tell you this. It's based on my 20+ years, 50 different teams and many hundreds, perhaps thousands of encounters with software developers. It's almost never the domain complexity that is high. Sending a rocket to Mars is complex. And perhaps complex every time. Dealing with people that has to work together can only be simplified when agreements are made and agreements are kept. Otherwise you cannot trust and have faith in people. It comes down to far and near organization leadership, mandate and empowerment in small teams with few communication links outwards, clear expectations from whomever is asking for something and process management. Writing code is rarely hard if you know the expectations and the boundaries of the task. Empowerment gives the team the possibility to act on what they discover and encounter. 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! One thing is complexity in code. Another is complexity in business. Some things are not made for software to solve. 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. Look for it I can go on because I help companies and teams for a living. But I will stop here

_gabe_ 4y ago
> 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! Yes! 100% this. We need less fortune tellers and more pragmatists.
0xFACEFEED 4y ago
> 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.

_gabe_ 4y ago

> 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! Yes! 100% this. We need less fortune tellers and more pragmatists.

0xFACEFEED 4y ago

> 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.