8 ms·
> Even bad estimates are better than no estimates. No estimate is clearly better. Here's a common story I've seen across multiple companies. 1. Marketing m
by bb88 7y ago
> Even bad estimates are better than no estimates.
No estimate is clearly better. Here's a common story I've seen across multiple companies.
1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign.
2. Engineering management then asks potentially good coder how long it will take. Coder replies with a time and "it's just an estimate."
3. Engineering management reports to Marketing that coder's estimate leaving off the most important caveat, and Marketing treats that as the gospel truth.
4. Coder takes longer than expected because of some bad technical cruft that some other engineer put in because he was potentially rushed or just plain inept.
5. Marketing is pissed because they now have to withdraw the ad campaign, and starts blaming engineering.
6. Under increased scrutiny, Engineering gets a bad reputation, who then throws the coder under the bus in front of Marketing and other managers.
7. This shows up on the coder's annual review who then leaves.
8. Engineering hires replacement which will have a 3-6 month learning cycle, and potentially writes worse code than the person that just left.
EDIT: The point is that if there's no estimate, management has to deal with the uncertainty that the coder experiences. Hope for the best, plan for the worst.
- 50656E6973 7y ago>1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign. Why can't Marketing just wait until the feature has been built to launch their campaign?
- bb88 7y agoLots of reasons: 1. Marketing management is full of idiots. 2. The coder's estimate is used to tell the CEO when a product will be rolled out. Who then questions why it didn't get rolled out on time. 3. Marketing gets a bonus for rolling out ad campaigns on time. 4. Marketing is using this for their big trade show coming up and wants to make a big announcement for maximum impact. Why do you assume management is always competent?
- rch 7y agoBecause if they launch on the original schedule with Partner X they get Massive Benefit Y that could make or break the product. For example.
- ScottFree 7y agoThis. Most developers either don't want to or can't understand that there are real and valid reasons for wanting a predictable software production schedule. That said, I've only ever seen one software project consistently meet production deadlines. Is there benefit to committing to the original schedule with Partner X if there's no way you can deliver on schedule? Or is it one of those things where Partner X has committed itself and they have no real choice but to work with the sliding deadlines?
- rch 7y agoIn the example I'm thinking of the partner wasn't really bothered that the schedule slipped, but the ideal marketing window came and went before the product officially launched, which certainly affected sales. They were really excited that all the planned features made it to market though. I'd say that some aspects of the capability maturity model make sense, even for engineering groups that practice agile day-to-day.
- ScottFree 7y ago> the ideal marketing window came and went before the product officially launched, which certainly affected sales. Definitely. I used to see that all the time in the games industry. Getting the right launch window is critical because most of a game's sales happen in the first few days of launch. And yet, games are famous for shipping months, even years late. They usually seem to make it work. I guess you'd be particularly hosed if you couldn't afford the burn rate for the extra X months it would take to get to a decent launch window.
- bobm_kite9 7y agoI think this comes down to the idea that estimates are really for coordination. At least, I think that’s the best reason for using estimates. I wrote something about this here: https://riskfirst.org/Estimates https://riskfirst.org/Estimates
- bobm_kite9 7y agoActually I don’t really understand why all the HN posts on agile just devolve into a discussion about the difficulty of estimating. Surely there’s more to it than that?
- ahelwer 7y agoWell, standup is also terrible. In addition, there's the general agile assumption that developers are capable of consistently producing X hours of work per day. Maybe it's just me, but I'm a bit more burst-y with my work habits than that.
- majikandy 7y agoI wouldn’t say Standup is terrible but one where you go round the room giving updates is almost useless. It’s not just you, most developers can do 8 hours work in an hour if they aren’t interrupted with meetings.
- Aeolun 7y agoShouldn’t it average out over 2 weeks?
- ahelwer 7y agoNot if you're doing standup every day and expected to report daily progress.
- TheOtherHobbes 7y agoBecause campaigns have to be planned ahead too - anywhere between a few weeks and a year or so, depending on the size of the project and the company, and often timed to match big trade events. And there's always the possibility that if you announce too late competitors will eat your lunch. One way to handle this is to spend some time on a formal estimate. Two to four weeks of R&D to scope a project can help narrow estimates to something approaching realism. You'll still be wrong, but you're less likely to be hopelessly wrong. Asking someone for an instant opinion is madness. That's not an informed estimate, it's just a guess, and usually worthless.
- fuzz4lyfe 7y agoSounds like marketing needs to be agile
- jldugger 7y agoBecause the superbowl comes once a year -- seasonality matters!
- gomox 7y agoOh come on. Any decent project manager understands the difference between an estimate and a deadline and plans and communicates accordingly. It's not rocket science. Stuff gets shipped on time all the time.
- ohithereyou 7y agoI want to work where you do, where friction is negligible, cows are perfectly spherical, wind resistance is never a factor, all functions are continuous and differentiable across their entire domain, and all project managers are decent.
- gomox 7y agoI'm not saying the story is implausible, but I dispute the idea that estimating software development efforts is an intractable problem that is better left unattempted.
- krageon 7y agoEstimating things is important and valuable, but as soon as you get large corporate structures and multiple levels of people communicating involved it becomes a really bad idea. That's why it shouldn't be attempted in those kinds of situations.
- bb88 7y agoThere's two issues right? 1. Inability to estimate effort. Admittedly an academic issue, and should be taught to all engineers in college. 2. Inability of management to deal with delays due to bad estimation. This might be caused by a "bozo explosion", say, (where inept managers hire more inept people underneath them.) Edited to add: 3. Why do we keep making assumptions that management must be infallible? In any dysfunctional organization, it might just take one bad manager high up in the chain that causes pain for the entire organization beneath him.
- redhale 7y ago
- rubidium 7y agoI’m sorry for your bad experience, but some companies are able to do this well.
- mbesto 7y ago> Hope for the best, plan for the worst. Oh dear, have you ever spoken to a finance department before? Here's a common story I've seen across multiple companies[0]. 1. The Finance department alots the marketing department with a $500k budget. 2. Marketing department blows through the $500k budget on the engineering department and has no productive app to speak to. 3. The Finance department goes back to the Marketing department asking what happen to all of the money they gave them. 4. The Marketing department says "well engineering told it was agile, which meant they didn't know when it would be done and for how much" 5. Finance department: "Ya, you're not getting a budget ever again from us" > No estimate is clearly better. Sorry, but this is not how the real world works. Agile assumes a perpetual budget, which is not realistic for most businesses in the world. [0] - Personally seen among 100+ and counting.
- bb88 7y agoI'm sorry, but if you're spending $500k or more based upon one engineer's "estimate" (for which you're paying $10k/month) then something is more fucked up in that company than what appears on the surface. But I agree with you, if the engineering management can't budget and prioritize work to get done, that's a larger issue.
- mbesto 7y ago> but if you're spending $500k or more based upon one engineer's "estimate" (for which you're paying $10k/month) The $500k was just a random number I came up with. Budgets wildly vary based on whether they get allocated weekly/quarterly/yearly/etc. And also it's never "one engineer's estimate", it's usually a project manager who works with N number of engineers to come up with an estimate.
- bb88 7y agoAnd that's the way it should be. But keep in mind that if a developer is in a sprint, he might start adding tickets to the epic because of technical/organizational issues. Suddenly the epic might look 3x more work than was originally planned. Note this is not theoretical, as it's happened 3 times to our team already this year. But meanwhile in the example I gave, the developer gets held accountable still for not making the correct estimate. Management just passes it up the chain rather than trying to increase the confidence around the estimate.
- karmelapple 7y agoWhat is plan for the worst in a scenario with literally zero estimate? “It may take 0 to 3 years” ? “We literally have no way of knowing?” “Not even a ballpark?” “No.” This is what you’ve proposed with no estimate, and this seems extremely unhelpful towards the goal of helping all groups at least have some idea when certain “next steps” can be accomplished.
- atoav 7y agoI work as a sound mixer for film and estimating how long it will take is always hard, but I never really got a bad reception when I just said: I canlt tell you unless I see the thing. Hell if you ask a mechanic to fix your car they will also have to check the thing first before deciding how long it is going to take. This is the professional thing to do: gauge the situation, take tour time to figure out the scale of the thing as long as you need and then give a pessimistic guess with a disclaimer that things can easily get out of hand without anybodies fault if unforseen problems arise.
- Traster 7y agoRight, but there's a big difference between "Don't estimate until you've done your due diligence" and "Don't estimate". It's perfectly reasonable to say "This is a big project, it'll take me a week to know where we stand"- there, you've provided an estimate of the scoping task and promised an estimate in the future as well.
- bob33212 7y agoMy advice would be to live in the real world. We don't know how long it is going to take. Just like if you go to turn on your car and it doesn't start. Maybe it was a minor issue and the next time you turn the key it will start. Maybe there was a short circuit and the car is totaled. A passenger asking you when you are going to get moving is no help.
- sopooneo 7y agoIf your car won’t start, it will take more than a second, but less than a year to fix. That is a bad estimate, but better than no estimate for a space alien that doesn’t know what a car is. PM’s are space aliens.
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]
- elindbe2 7y agoIt's even worse in my organization. Funding is based on projects so the amount of funding you receive is based on exactly how long your estimate is (if they choose to fund your project). Often projects are estimated based on "here's how much money they are willing to spend, so we'll just figure out the number of man hours that amounts to and give that as an estimate."
- notyourday 7y ago> No estimate is clearly better. Here's a common story I've seen across multiple companies. As strange as it may sound to developers, the salary is paid by the customers, current or future.