8 ms·
>>The engineer's boss, an engineering manager, asks him how long a new task will take to complete. Sometimes the engineer has not done this particular thing bef
by TuringNYC 6y ago
>>The engineer's boss, an engineering manager, asks him how long a new task will take to complete. Sometimes the engineer has not done this particular thing before, so he responds honestly that he has no idea how long it will take. His boss will not accept that answer. He asks again. So, the engineer makes a wild guess and his boss responds with, "That's too long." Even if the engineer knows how long a task will take to complete and gives a realistic estimate, his boss often responds with, "That's too long. You have until Friday." When the engineer asks how long his boss has known about the task, the boss says he has known for a month. When the engineer asks why he didn't tell him a month ago, the boss just looks at the engineer like he doesn't understand the question.
If this describes your workplace, please find a better managed workplace if you can. They are out there
The correct way to do things here would be to:
1. Do a probe project to evaluate complexity and/or look at similar projects
2. Trade time (deadlines) for scope and resources. Yes, we can deliver in a month, but only if we cut scope and get 2 more QA folks, etc.
EDIT 2a: You can also negotiate to trade time for quality and/or take on technical debt knowing it reduces future velocity.
3. If neither of the above happen, you should trade absurdity for more salary/growth. I've seen this at places such as hedge funds and consultancies and they compensate and "pay" for it with better comp and growth.
- m463 6y agoI would also read books by steve mcconnell. The book on software estimation is awesome with respect to schedule. Just taking the quiz at the beginning of the book is eye-opening.
- cwillu 6y agoFor those interested in the quiz: https://books.google.ca/books?id=U5VCAwAAQBAJ&lpg=PP1&pg=PT58#v=onepage&q&f=false https://books.google.ca/books?id=U5VCAwAAQBAJ&lpg=PP1&pg=PT5...
- Zippogriff 6y agoWhat's supposed to be the take-away from this? Is it to prove that knowing one or two bits of trivia and maybe a formula, by rote, can make your (unaided) estimation of related things vastly more accurate? That's all I'm getting from it, but maybe that's what's intended. Examples: if I didn't happen to have an accurate-enough figure for the diameter of the Earth in miles, plus a formula for the surface area of a sphere, plus roughly the proportion of the Earth's surface that's land, all in my head, there's no chance at all I could produce a useful-for-any-purpose-whatsoever estimate of "area of the Asian continent" without researching it (at which point I could just look up a fairly exact figure, without knowing any of that). Year of Alexander the Great's birth, well I happen to know roughly when Aristotle was active and that they were alive at the same time. Otherwise, again, I'd produce a useless-for-most-any-purpose guess. Total US currency, I bet knowing something like the current annual GDP of the US would at least narrow that down, and is something someone might plausibly have at hand (I don't, my guessed range on that would be hilariously bad). If you have a sense of blockbuster movie budgets and/or returns, which one can acquire from paying attention to entertainment headlines, it's easy to come up with a reasonable range for Titanic's box office receipts. And so on. Is the point that trivia's highly valuable, actually, if you have to estimate a bunch of arbitrary stuff purely from memory?
- jpeloquin 6y agoThe quiz asks for a range that will include the correct answer 9/10 times. Not a point estimate. If you don't have the relevant trivia in your head, broaden the range proportionally. I think the intended point is that we're bad at judging probabilities. Getting 100% right (within range) is probably supposed to be as concerning as getting 0% right.
- depressedpanda 6y agoContinue reading, especially the part titled 'How representative is this quiz of real software estimates?', and you'll get to the author's point.
- Zippogriff 6y agoAh, right, I've always taken that effect in software estimation to be a result of business people hating how wide an actual "90% accurate" estimate is. Not many managers will accept "8 to 30 months" as a 90% estimate at the start of a project with a fairly typical set of unknowns. Especially they seem to really hate ranges that aren't quite a lot narrower than the size of the lower bound. But maybe it's actually driven by the people doing the estimating. For my part I definitely tend to squeeze my "90%"s down to more like "30-40%" when asked for a "90%", for that reason. I might try out an honest and accurate estimate on someone I kinda know, and suspect won't quietly re-evaluate me as a useless moron or "one of those asshole 'programmer' types who doesn't get business" in response, though.
- klmadfejno 6y agoNumber 2 is very important and not obvious. Give your manager options to choose from. It makes you a cooperative problem solver rather than someone who is pessimistic and can't manage deadlines. Shrugging and saying that scope management is the manager's job is equally as bad as the manager shrugging and saying implementation is the dev's job. Applies to non-dev work as well.
- sidlls 6y agoAnd what happens when your manager’s response is “you’re the expert, I expect you to decide these things?” This industry is like any (every?) other: a minefield of incompetence and laziness interwoven with an unhealthy dose of unjustifiable arrogance.
- TuringNYC 6y agoIn some ways, that might be a good situation -- it means they are leaving all the trade-off decisions to you. If they are only specifying time and resources, you can trade scope, quality, debt. If they are freezing time and resources and scope, and you dont have much room to move except with quality and debt. But those catch up. If that is the consistent trade-off, i'd go with my original recommendations: trade this stupidity for more salary or find a new employer with better management. Or seek the managerial position yourself and do a better job at it.
- nthj 6y agoAlways provide options and a recommendation.
- CogitoCogito 6y agoIf this doesn't work, then I think the most important thing is to implement the most simplistic basic solution as fast as possible and then explicitly ask for feedback. Hard-code whatever portions that take time, but you're not worried about (e.g. database portions). Focus on the parts that are vague that you don't understand and provide a _concrete_ realization of the those vague ideas. This shifts decision-making responsibility away from you. As a plus this also gives you the ability to more effectively gauge the difficulty of the rest of the project. The things you thought were simple might be much worse. And then as long as you get concrete feedback, you'll be able to much better predict the amount of time and effort required going forward.
- matheusmoreira 6y agoWhy can't engineers simply tell managers that it can't be done by the specified deadline? Why do managers even ask this question if they're gonna ignore the answer and impose an impossible deadline anyway? It looks like they're assuming we're all lazy. They think the job isn't that hard. A fundamental lack of respect.
- drdeadringer 6y agoPerhaps some managers think they are a clever Cpt Kirk who's gotten wise to their Scotty's miracle-worker tactics, even though they're a manager with an honest Geordi La Forge. No offence to Geordi La Forge.
- watwut 6y agoBecause in majority of the case engineers after manage to hit the deadline. That is managerial experience. What management learns over time is that engineers say it is impossible but if you insist they will then do it. It is by trading quality pretty often, but that often is exactly trade off managers want. It is often by trading future productivity - engineers burning out or at least having drop after deadline.
- matheusmoreira 6y ago> It is often by trading future productivity - engineers burning out or at least having drop after deadline. Future productivity? If engineers are burning out in an attempt to meet otherwise impossible deadlines, it means they're being placed under enough stress that it's threatening their mental and possibly physical health. Is employee health really something that can be traded away?
- KKKKkkkk1 6y ago> If neither of the above happen, you should trade absurdity for more salary/growth. I've seen this at places such as hedge funds and consultancies and they compensate and "pay" for it with better comp and growth. I traded stupidity for money. Don't do it.
- TuringNYC 6y agoHighly recommended read: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s... My recommendation: try to evaluate your employer on the above. I've traded stupidity for money for money earlier in my life, and it made sense. But people underestimate the break-even. You deserve a lot of money (50% or 75% premium) for some of the stupidity I've seen. On the flip side, i've also traded a salary discount for a well-run org -- a job where i have 90min max meetings a day with lots of good ASYNC communications, good project planning, estimation, and good sprint cadences. I work a lot, but only when I want to (often late nights), bike outside when I want to, work heads-down w/o disturbances, etc. Just be careful when headhunters come offering a 10 or 15% increase in comp except w/ a very different culture. You have to compare like to like.
- hobofan 6y ago> My recommendation: try to evaluate your employer on the above. And better do it in a nuanced way, not the yes/no checkmarks that Stackoverflow Jobs is using for those points. I've worked for companies that were a mess and would get 11/12, as they _technically_ were using source control and tracking bugs etc., just in the most unproductive/useless way.
- WrtCdEvrydy 6y ago> I've worked for companies that were a mess and would get 11/12, as they _technically_ were using source control and tracking bugs etc., just in the most unproductive/useless way. ie: Security Auditing Style...
- jnwatson 6y ago
- hkmurakami 6y agoThis reads more like the"engineering manager" has had a sales role for too long. I think most frequently this is at the VP level. The direct eng manager (or PM sometimes) should be in a position to fight against this sort of absurdity, give the IC a few days to scope the project, etc. One of the eng managers at a previous employer wasnt a great technical mind but was stellar at playing defense against managament. We all had great respect for him repeatedly taking it on the chin for his team.
- majormajor 6y agoYeah, anyone who knows about a deadline for a project for a month and hasn't bothered scoping it or estimating with their team is massively failing at their job.
- babesh 6y agoMost tech companies are set up such that managers are not incentivized to play defense for their team. Managers switch teams too often (usually on an annual cycle). Teams get reorganized almost as often. Managers have to please their boss or someone higher up. The power the engineers have is to exit. In some organizations, the engineers can exit to another part of the organization. In others, they exit the organization entirely. This does actually work in aggregate if you just look at it on a longer timescale.
- taigeair 6y agodo you have any career development book recommendations?
- tootie 6y agoI'm a manager who has to speak directly to paying customers about how long they have to wait to get what they paid for and even I will never give a deadline or date. Most customers are actually pretty reasonable and know you can't predict everything. Most are thoroughly aware of how terrible they are at giving clear direction. It's important as a leader to exactly why things take time or why timing is unclear. Risks, uncertainty, quality takes time. There's also plenty of things you can do as a manager to de-risk a delivery and avoid being bottlenecked by risky tasks. It's also much easier (not easy, but easier) to estimate larger buckets of tasks than individual ones knowing that some will be harder than expected and some will be faster.
- binarytox1n 6y agoI agree with this wholeheartedly. The article seems to be written by someone who has not yet learned the life lesson that "everything is a negotiation". There's no such thing as a hard deadline. Everything is made up. What your manager is saying is: "To be successful in the market, I think I need to have X thing in Y days." It's the engineer's responsibility to provide information and estimates that will shape the business's direction. If you don't clarify or negotiate requirements based on your technical knowledge and experience and just take requirements as law written in stone you are not providing the true value of an engineer. If you are doing that - pushing back and grounding requirements in reality - and the business plows ahead with unrealistic goals anyway, then that simply means the people you work with are unreasonable and you should seek employment elsewhere. If they're not even willing to listen to people they're paying to have expertise then they're probably reading the market wrong too and I wouldn't trust them to be around long anyway.
- ip26 6y agoThere's no such thing as a hard deadline. Everything is made up. "This video processing software needs to be ready by the Superbowl" or "This electronic voting software needs to be done by election day" don't strike you as hard deadlines?
- robocat 6y agoOften this video processing software wasn’t ready by the Superbowl, and this electronic voting software wasn’t completed by election day. You don’t get sacked, you just get to work on the next death-march project. And for your two examples, it might be punted to the next Superbowl or election. Hard deadlines are not often deadly.
- ip26 6y agoSo, what, it's only a true S̶c̶o̶t̶t̶s̶m̶a̶n̶ hard deadline if missing it means the guillotine?
- 6y ago
- temp667 6y agoI traded absurdity for salary. I just said, I'll need to work Saturdays to make this happen, and will need at least 2 others in on Saturdays (in office - full day work). I asked for +50% and got it. It helped I'd been clear that my schedule was 8:30-5:00 M-F to start and was younger at the time. Ironically - these days I just wish I had free time and curse myself fairly often for being over-committed. So rarely worth it even for more $ especially if you have kids and are a stranger to them. While I'm paid extremely well QOL is WAY down and stress is very high.
- chromedev 6y agoI feel like large companies see developers/engineers like a commodity, give them a spoon and tell them to move a mound of sand. As soon as you tell them you have a shovel, they'll say... well we have spoons, we've always used spoons and you need to continue to use a spoon. We have managers and vendors that take them out golfing that we pay millions of dollars to and we signed a 5 year contract to use spoons, so use a spoon.