5 ms·
and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them t
by mden 8y ago
and no one is willing to say so.
Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number.
On the reverse of course it makes sense to have estimates otherwise how should managers or product people decide what should be done next?
A big part of the issue is we don't have good knowledge how to estimate work. It's not a skill that is heavily invested in and is wrongly assumed as an inherent ability.
- rossdavidh 8y agoI have, on more than one occasion, said so, and the response was always bafflement or annoyance, and in either case and unwillingness to accept that answer. When I was younger, I would eventually give a guess, along with a "...but that's just a guess". Nowadays, I don't even give that, because the caveats get forgotten/ignored.
- codycraven 8y agoI have this sort of discussion, at minimum, three times a week (we're in-house developers). Very often the project scope isn't even defined and upstream dependencies are known to be critically lacking and will need to be augmented to even perform the work. Yet we're always pressured for dates and the caveats given are immediately forgotten and almost never communicated. The biggest pet peeve is when I give an estimate such as "I don't currently see a reason why we can't deliver X by the end of next week, assuming no other priorities come up." Of course something more important comes up in the mean time and I get scolded in a large meeting with a statement such as "You promised me I'd have X by Friday!" — this is especially infuriating when it is the PM's other project that is the higher priority interruption.
- lifeisstillgood 8y agoIt might not be viable, but I used to "publish" internally my own project one pagers, and update the timelines - any discrepancies simply became a shield for this future arguments. In short it sounds like you don't have the power to say no - but actually you do.
- watwut 8y agoInstead of caveats, add to the estimate. Every caveat is some additional time. Another thing that helped us is to answer with ranges instead of dates e.g., "this will take 1-3 weeks".
- chimprich 8y agoIt doesn't get a lot of love on HN, but these problems are addressed by Scrum. Sprints have a pre-allocated amount of work in them, which makes estimating easier. You can't predict exactly how much time you'll lose through meetings and emergencies, but estimating in story points will add a rough statistical estimate. Of course, if you already have a toxic development culture like the one you describe, then they'd probably abuse more agile processes too.
- jadedmgr 8y agoAs a manager over a new project with a ridiculous release date, I'm subject to the same political bullshit as everyone else. At this point, I'm of the opinion that anything with a realistic ship date simply won't get funded. So all I do these days is commit to things that I am certain aren't achievable in the time frame on the table, just so that we can get the project off the ground in the first place. From that point, I immediately start to play the game of politics and showmanship to put together a narrative with the usual culprits for why a project is late. Shifting requirements, other teams that didn't deliver what we depended on, etc. Then I make more promises and estimates, playing the emotional card of "sunk cost" to convince upper management to continue funding the team rather than torpedo the project. Then we ship, and I quickly get everyone on my team promoted "because we shipped" before it becomes clear to upper management that we shipped something essentially worthless to the company. Because we're in a huge profitable company, everyone can jump ship to the next shiny thing, and whoever is left holding the potato on its way to deprecation just gets re-org'd when it gets canned. I know it's a bullshit game. But I play it well, and all the software developers on my team get paid and promoted because I am so good at it.
- lifeisstillgood 8y agoOne day you might play it so well, you find yourself on the Board. Will you then argue that all new projects should avoid deadline dates, that no project should have anything other than an MVP and a iteration plan after that? How do we change the expectations?
- natalyarostova 8y agoLol holy shit, this explains so much of my experience that I never even knew.
- Techonomicon 8y agoYou're subject to the "same political bullshit" because you choose to be. You don't have to partake in it, but you do. You can choose not to, you can choose to try to bring the company around you to greener pastures - but you don't. You sound wise and such in general, but perhaps your time would be better spent making a difference in how people believe work should be done at a place that actually allows brewing better practices instead of lauding bad ones.
- marvin 8y agoI had this experience recently. We don't use a lot of detailed estimates in my team, because the work needs to be done regardless, and the estimates are then largely a waste of time. But there was one occasion, where a product launch had been announced by a C*O before the product was finished, and the engineers were very clear that this launch date was impossible. So there was a lot of drama and bad feelings, and the engineering team eventually said, "okay, let's make a detailed estimate so we can be certain". The estimate came in at three weeks development time, one week after the announced launch date. One week of the estimate was meant for testing and fixing problems that are found in testing. The business experts immediately jumped on this: "Testing and fixing unplanned errors won't be a big deal and certainly not a whole week. We'll skip that so we can get it done in two weeks". Thankfully, this is retail banking, so releasing an obviously broken product flies even less than missing the deadline. The product was eventually launched uneventfully, one week after the detailed estimate and two weeks after the announced launch date. All in all a success.