4 ms·

Thank God somebody said this. When I was working as an IC, I would be very communicative, highlight the unknowns, and get buy-in from my boss. If a surprise cam

Thank God somebody said this. When I was working as an IC, I would be very communicative, highlight the unknowns, and get buy-in from my boss. If a surprise came up, I would make sure everyone knew the game had changed. As a manager now, I get scoffed at if I even hint at a deadline. Excuse me what? We have a limited budget, a limited runway, and we need to prioritize which product bets we are going to make. This seems entirely logical, but a lot of devs I work with now find it impossible. They just enjoy tinkering away with whatever thing interests them, and delivering value only means what they personally find valuable. Personally, I find it a bit pathetic and childish. I say this as a long time software engineer who knows perfectly well how this business works.

pylua 4y ago
Will Wright had a quote on this … if you don’t have any constraints you are just playing. That said, however, The problem I run into during practice is dependencies— people want estimates to integrate into systems you have never heard of or used before. Not only that, there is no in place architecture or design before estimation. Imagine a construction company estimating a house without knowing how big it is or without having blueprints. Often times software development is designing and architecting the system — not just implementing it. And that is the expensive part.
- mewpmewp2 4y ago
  Then you communicate! Say that the estimation can depend on the complexity of the system. I would think worst case is when the system has these A, B problems, then it would take N time. Otherwise best case it could take M time. If we want more accurate idea, we can spend O time on it to figure out what it could be.
  - pylua 4y ago
    I would say this is being negligent if it is generalized. Often times architecting a system involves meetings with multiple parties — stake holders , legal counsels, and months or years of planning ahead to give a proper estimate for a large system. Time and materials is the right way to do this. However I can see this working in a very small scenario.
re-thc 4y ago
> Personally, I find it a bit pathetic and childish. I say this as a long time software engineer who knows perfectly well how this business works. How does this business work? Why is software special? This happens the same in construction and other industries. The estimates usually make 0 sense and there are often huge delays. Same as store openings, film production, etc. There's a problem with tinkering and devs going off in the wrong direction but on the flip side when people say that something is done in an hour or a day often never happens. Managers and agile practices that want tasks broken done to the smallest atom just messes things up. To make things work product often never has accurate requirements to that detail either so that complicates things even more. The requirements change on the fly.

pylua 4y ago

Will Wright had a quote on this … if you don’t have any constraints you are just playing. That said, however, The problem I run into during practice is dependencies— people want estimates to integrate into systems you have never heard of or used before. Not only that, there is no in place architecture or design before estimation. Imagine a construction company estimating a house without knowing how big it is or without having blueprints. Often times software development is designing and architecting the system — not just implementing it. And that is the expensive part.

mewpmewp2 4y ago
Then you communicate! Say that the estimation can depend on the complexity of the system. I would think worst case is when the system has these A, B problems, then it would take N time. Otherwise best case it could take M time. If we want more accurate idea, we can spend O time on it to figure out what it could be.
- pylua 4y ago
  I would say this is being negligent if it is generalized. Often times architecting a system involves meetings with multiple parties — stake holders , legal counsels, and months or years of planning ahead to give a proper estimate for a large system. Time and materials is the right way to do this. However I can see this working in a very small scenario.

re-thc 4y ago

> Personally, I find it a bit pathetic and childish. I say this as a long time software engineer who knows perfectly well how this business works. How does this business work? Why is software special? This happens the same in construction and other industries. The estimates usually make 0 sense and there are often huge delays. Same as store openings, film production, etc. There's a problem with tinkering and devs going off in the wrong direction but on the flip side when people say that something is done in an hour or a day often never happens. Managers and agile practices that want tasks broken done to the smallest atom just messes things up. To make things work product often never has accurate requirements to that detail either so that complicates things even more. The requirements change on the fly.