5 ms·

why shorter is always better than longer?

egwor 3y ago
I came here to ask this too. I've had recent examples where the business has explicitly said the opposite (but we're long term greedy). I'm sure there are businesses on the verge of collapse where staying alive is the objective function. I'd be interested if there are other more common/healthy situations?
dubcanada 3y ago
The OP is talking about business, so having something done in 2 days versus 4 days is always better. Ignoring everything else, less time is less money.
- onionisafruit 3y ago
  And on the other end, that’s two more days that the company gets the benefit of your new software.
- gnulinux 3y ago
  > Ignoring everything else This is the problem with these kind of discussions. You cannot ignore everything else because everything else depends on 2 versus 4 days as well. Something that's done in 2 days can be exponentially worse than something done in 4 days such that in 6 months you can look back and rationally determine it was better to do it in 4 days.
sokoloff 3y ago
Unless you’re in the business of “selling hours”, why wouldn’t having something valuable done more quickly (and thus at a lower expense) be better, all else being equal? Sure, if you’re a contract dev shop who is marking up hours, then longer is better.
- jeltz 3y ago
  From my experience this is simply not true because all else is never equal. Employee burnout, technical debt, risks taken due to rushing, people not doing the right tradeoffs, etc.
  - wkat4242 3y ago
    Nobody cares about doing things right anymore. They just want quick wins. Meanwhile all the tech debt piles up.
    - latency-guy2 3y ago
      Seeing as there's tech debt from 40 years ago people like me are still paying, seems like devs don't know how to do things right at all.
      - wkat4242 3y ago
        Well yes and no. That tech debt from 40 years ago was usually perfectly adequate back then. It's only tech debt now because it's become unmanageable due to changing environments, programming languages, APIs, security concerns etc.
  - gnulinux 3y ago
    > Employee burnout, technical debt, risks taken due to rushing, people not doing the right tradeoffs, etc. I've never seen a set of business people in a software company that cares about any of these things. Some PMs will say they care about tech debt which excites me but of course in 6 months you'll see they actually cannot give a shit but just use it as a tool to lower the estimates. If X takes 5 days but they want 3 they'll tell you "let's just add some tech debt" to convince you to promise 3, but they don't actually ever intend to work on that tech debt. When it comes to burnout, I've literally never seen any person who doesn't consider this the fault of the employee. I've seen VP level people who did things that are so absolutely insane that it resulted the project to be late with 100% probably from 6 months before, then when the day of launch comes it is indeed late, fire alarms are pulled, tons of people give on-call attention to our project, we hack something. Then VP says "whoopies sorry about the fire alarm, will never happen again". Lmao next thing that happens is that this person is promoted to SVP and does it again and again. "Rushing" is a good thing, if anything. Business is all about creating an artificial sense of urgency that could be trivially averted, but it was chosen not to. People not doing right trade offs. Well again, it's on you if you do the wrong trade off. People will point at you and say this decision was wrong. That I had so little information and time to make that decision is very brought up.
- jabradoodle 3y ago
  A lot of the time getting things done more quickly equates to creating a mess that will cost you more in the long run. That's why it's called tech debt, it accrues interest.

I came here to ask this too. I've had recent examples where the business has explicitly said the opposite (but we're long term greedy). I'm sure there are businesses on the verge of collapse where staying alive is the objective function. I'd be interested if there are other more common/healthy situations?

dubcanada 3y ago

The OP is talking about business, so having something done in 2 days versus 4 days is always better. Ignoring everything else, less time is less money.

onionisafruit 3y ago
And on the other end, that’s two more days that the company gets the benefit of your new software.
gnulinux 3y ago
> Ignoring everything else This is the problem with these kind of discussions. You cannot ignore everything else because everything else depends on 2 versus 4 days as well. Something that's done in 2 days can be exponentially worse than something done in 4 days such that in 6 months you can look back and rationally determine it was better to do it in 4 days.

sokoloff 3y ago

Unless you’re in the business of “selling hours”, why wouldn’t having something valuable done more quickly (and thus at a lower expense) be better, all else being equal? Sure, if you’re a contract dev shop who is marking up hours, then longer is better.

jeltz 3y ago
From my experience this is simply not true because all else is never equal. Employee burnout, technical debt, risks taken due to rushing, people not doing the right tradeoffs, etc.
- wkat4242 3y ago
  Nobody cares about doing things right anymore. They just want quick wins. Meanwhile all the tech debt piles up.
  - latency-guy2 3y ago
    Seeing as there's tech debt from 40 years ago people like me are still paying, seems like devs don't know how to do things right at all.
    - wkat4242 3y ago
      Well yes and no. That tech debt from 40 years ago was usually perfectly adequate back then. It's only tech debt now because it's become unmanageable due to changing environments, programming languages, APIs, security concerns etc.
- gnulinux 3y ago
  > Employee burnout, technical debt, risks taken due to rushing, people not doing the right tradeoffs, etc. I've never seen a set of business people in a software company that cares about any of these things. Some PMs will say they care about tech debt which excites me but of course in 6 months you'll see they actually cannot give a shit but just use it as a tool to lower the estimates. If X takes 5 days but they want 3 they'll tell you "let's just add some tech debt" to convince you to promise 3, but they don't actually ever intend to work on that tech debt. When it comes to burnout, I've literally never seen any person who doesn't consider this the fault of the employee. I've seen VP level people who did things that are so absolutely insane that it resulted the project to be late with 100% probably from 6 months before, then when the day of launch comes it is indeed late, fire alarms are pulled, tons of people give on-call attention to our project, we hack something. Then VP says "whoopies sorry about the fire alarm, will never happen again". Lmao next thing that happens is that this person is promoted to SVP and does it again and again. "Rushing" is a good thing, if anything. Business is all about creating an artificial sense of urgency that could be trivially averted, but it was chosen not to. People not doing right trade offs. Well again, it's on you if you do the wrong trade off. People will point at you and say this decision was wrong. That I had so little information and time to make that decision is very brought up.
jabradoodle 3y ago
A lot of the time getting things done more quickly equates to creating a mess that will cost you more in the long run. That's why it's called tech debt, it accrues interest.