4 ms·

Why would you change plans and expect the construction crew's prior estimate to remain unchanged? Estimates change if the project changes. A commercial develo

Why would you change plans and expect the construction crew's prior estimate to remain unchanged? Estimates change if the project changes. A commercial developer's job includes recognizing that and communicating changes upstream. Usually that leads to a negotiation, collectively determining how much to (try to) spend and which boondoggles are trutly important. If a hired software developer told me up front, "I can't estimate because you will change things and then the old estimate will be wrong," all I can conclude is that this relationship is already dysfunctional.

mumblemumble 4y ago
> I can conclude is that this relationship is already dysfunctional. Here's the thing, though: you wouldn't be wrong. It may be different for contract development. For in-house development though, everywhere I've worked we've all always known that the relationship is dysfunctional. We also know that the dysfunction is everyone else's fault, not our own. So we just put up with it, because those assholes will never consent to fixing it, anyway, and just try to shift the blame to us instead.
- ycombobreaker 4y ago
  Yeah I'm used to in-house, no material contract experience. > the dysfunction is everyone else's fault, not our own I specifically said the relationship. It takes two parties for effective communication to occur. An engineer who have given up trying because they assume experienced management will not listen, is just as bad as a manager that steamrolls their experienced engineers.
  - mumblemumble 4y ago
    Yeah. What I'm getting at is that I think the relationship is doomed to dysfunction by a dysfunctional culture.
rqtwteye 4y ago
In most companies it works this way "Give me an estimate based on what I am telling you now. I haven't really thought it through and there are a lot of unknowns I view this estimate as a commitment that should be kept although I will probably make a lot of changes during development"
- scruple 4y ago
  I think this is close. IMO, the problem is that we're talking about a group of concepts using vague language. Is it an estimate, a target, or a deadline? "Estimate" gets used in place for targets and deadlines all of the time and it sets up situations where expectations aren't properly managed.
mawadev 4y ago
This is the trick, everyone in the room knows it makes no sense. You change the requirements and then hold someone accountable for an estimate that is based off of different, often simpler requirements. What you do is extract an extra amount of economic output out of your worker, who wouldn't say no to that? Then when it hits the wall, it's the dev's fault anyway. If it works out, you get a pat on the back! If the dev says NO, the dev will still have to do the work and may even be coerced into doing so. Many junior developers think it's their fault, but they're being manipulated. That's why nobody likes seniors, too.

mumblemumble 4y ago

> I can conclude is that this relationship is already dysfunctional. Here's the thing, though: you wouldn't be wrong. It may be different for contract development. For in-house development though, everywhere I've worked we've all always known that the relationship is dysfunctional. We also know that the dysfunction is everyone else's fault, not our own. So we just put up with it, because those assholes will never consent to fixing it, anyway, and just try to shift the blame to us instead.

ycombobreaker 4y ago
Yeah I'm used to in-house, no material contract experience. > the dysfunction is everyone else's fault, not our own I specifically said the relationship. It takes two parties for effective communication to occur. An engineer who have given up trying because they assume experienced management will not listen, is just as bad as a manager that steamrolls their experienced engineers.
- mumblemumble 4y ago
  Yeah. What I'm getting at is that I think the relationship is doomed to dysfunction by a dysfunctional culture.

rqtwteye 4y ago

In most companies it works this way "Give me an estimate based on what I am telling you now. I haven't really thought it through and there are a lot of unknowns I view this estimate as a commitment that should be kept although I will probably make a lot of changes during development"

scruple 4y ago
I think this is close. IMO, the problem is that we're talking about a group of concepts using vague language. Is it an estimate, a target, or a deadline? "Estimate" gets used in place for targets and deadlines all of the time and it sets up situations where expectations aren't properly managed.

mawadev 4y ago

This is the trick, everyone in the room knows it makes no sense. You change the requirements and then hold someone accountable for an estimate that is based off of different, often simpler requirements. What you do is extract an extra amount of economic output out of your worker, who wouldn't say no to that? Then when it hits the wall, it's the dev's fault anyway. If it works out, you get a pat on the back! If the dev says NO, the dev will still have to do the work and may even be coerced into doing so. Many junior developers think it's their fault, but they're being manipulated. That's why nobody likes seniors, too.