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.
“It may take 0 to 3 years” ?
“We literally have no way of knowing?”
“Not even a ballpark?”
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.
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.
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.
PM’s are space aliens.
A PM with a deep understanding of the software process, can ask insightful questions, identify and possibly mitigate many of the issues beforehand. So when it gets to the software lackeys, many of the resource/architectural issues may have been solved.
It's actually a better estimate than most software estimstes, because it isn't just an expected time but a range that results will usually fall within. It would be better if it included an explicit degree of confidence that th actual result would be in the range, and if it was centered around the average time it would take for events in the class.
Then again, a similar number of times, the only information you get is ‘we need a chat program, can you please estimate how long that will take?’. Which will leave it forever impossible to estimate.
That's when the engineering lead or whoever was giving that as the answer is told that his services are no longer required.
In my book, that project manager is not "decent". A decent project manager would recognize the situation for what it is and leave.
Deadlines can be legitimate project requirements as much as functional requirements are. Identifying practical conflicts between requirements is part of what an engineering team does. Managing resolution of those once they are identified so that the customer gets the best result achievable is what a PM does.
This is exactly it. Well said!
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.
As much as I did not particularly care for the management style of Steve Jobs, as far as I know, he was the one that first used the term.
This just happened recently. Maybe you'll appreciate it.
15 years ago or so (before the term "technical debt" got widespread usage) management kept asking why we working on so many bugs. The solution was to label them as "enhancements".
Just recently within the past year, I saw the exact same thing happen again.
Amazon took that to heart. Seems to have worked out for them.
Oh dear, have you ever spoken to a finance department before?
Here's a common story I've seen across multiple companies.
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.
 - Personally seen among 100+ and counting.
Unless, you know, there are other systemic issues in the company.
But I agree with you, if the engineering management can't budget and prioritize work to get done, that's a larger issue.
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.
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.
As strange as it may sound to developers, the salary is paid by the customers, current or future.
Why can't Marketing just wait until the feature has been built to launch their campaign?
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.
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?
I'd say that some aspects of the capability maturity model make sense, even for engineering groups that practice agile day-to-day.
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.
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?
At least, I think that’s the best reason for using estimates. I wrote something about this here:
Surely there’s more to it than that?