Software Estimation Is Hard. Do It Anyway.
Posted by alodiasaradith07@reddit | programming | View on Reddit | 87 comments
Posted by alodiasaradith07@reddit | programming | View on Reddit | 87 comments
A1oso@reddit
It has been suggested that software engineers are good at estimating the median time, but bad at estimating the average. This makes sense if you, for example, a feature will most likely take 3 days, but there is a small chance it will be finished in 2, as well as a small chance that you run into a roadblock and it ends up taking 3 weeks.
So when you estimate, you have to take uncertainty into account: The more can go wrong, the higher your estimate has to be. This is why seasoned engineers are better at estimating who know the code base well and are good at anticipating roadblocks.
jobe_br@reddit
Estimation isn’t hard. It’s a lie in every way that matters. Think about when you need to give an estimate, versus just saying when something will be done, within a small range. Whether in this industry or any other, an estimate is used when there’s uncertainty and unknowns. In this industry, however, the uncertainty and unknowns are a much bigger deal than in others. When developing novel software, we are in a complex domain. Not complicated, complex. That’s the difference.
Estimating in software means ignoring the reality that we’re working in the complex domain where cause and effect aren’t connected in the same way. Sales, marketing, and everyone else will sleep better understanding this versus believing in software estimates.
There’s a reason IT/software is despised more than legal by the business … and it ain’t that nobody’s giving estimates.
bwainfweeze@reddit
Maintenance work on old devices or houses can balloon rather marvelously. You won’t know what’s going on until you open it up and things could be way worse than you thought.
jobe_br@reddit
Yep, that’s very true, but even so, it’s still more in the complicated domain than in the complex. Especially when viewed from the perspective of a trade professional. Now, if you add elements like, the building is a historical site, or similar where you introduce a human element, bureaucracy, etc., you can start veering into the complex.
patrickprunty1997@reddit
The trickiest part for me is figuring out how long it’ll take to test reliability, handle integration in mature systems, and get PR approvals.
When it comes to development, things can usually get done and shipped pretty quickly, especially today with LLMs helping out.
But if the team gets too caught up in testing, PR approvals, and debating their agile processes, it can turn a very talented group into one that never actually delivers.
Confident_Fly7173@reddit
What PR what integration? We had an understanding that your estimate is for all these included, including the 100 times your Jenkins or CI/CD pipelines get stuck or down. /s
Confident_Fly7173@reddit
What PR what integration? We had an understanding that your estimate is for all these included, including the 100 times your Jenkins or CI/CD pipelines get stuck or down. /s
Anders_A@reddit
In an older codebase, most of the work is to figure out what to do unless you're willing to just add to the pile of unmaintainable crap. Trying to estimate without first doing that is pointless. It has zero chance of giving any number close to reality.
Confident_Fly7173@reddit
No you only estimate the effort required assuming to pretty well know the existing code base. Rest of it you are whining and not a team player /s
itijara@reddit
One thing this is missing (on the next part of the series) is that you can't just add individual estimates to get a complete estimate. Sequencing is vital, so that some things can only be done after others are complete and the longest such sequence in a project determines the time timeline. That means that in the best case scenario three tasks that take 1 week can be completed in one week if they can be done concurrently and you have enough developers to do all of them at once, and in the worst case they take a minimum of three weeks (and usually much longer).
This is a mistake I see a lot of engineering managers do: they take all the "points" for a project and divide by the average velocity of the team to get the estimated time, but really you need to plot out the critical path (and add significant buffer) to get a more realistic estimate.
suddencactus@reddit
Ultimately though, Gannt charts are an attempt to plan around and even condone dependencies. This may be reasonable for something like an external order, but what about other things like "we need a month to fully test each release after the code is written", or "these two teams can't work together effectively so we need team A to add library support before team B can add the feature"? Just planning around a long, slow blocker is a crude solution.
itijara@reddit
You are the second commenter to mention Gannt charts, when I didn't mention them at all. Using the "critical path" as part of establishing a timeline is one part of project estimation whether or not you use a Gannt chart. I don't.
I just use the critical path as the absolute baseline for the total estimate for the project (usually by comparing to previous). If a project with a critical path of 60 points took 3 months in the past, that is as good an estimate as any for the current. The total points in the project is much less indicative of how long it will take than the critical path. I also don't advocate for simply adding critical path estimates end-to-end as that is guaranteed to be wrong. As soon as one slips, the whole project slips. You need to add tons of slack.
suddencactus@reddit
True, you were talking more about general sequencing than Gantt charts' specific approach to managing critical chains. Regardless, my point still applies that too many companies are happy to throw a few hours a week of a managers' time on estimating and managing a critical chain instead of assigning someone to rearchitect the worst parts of the critical chain.
bwainfweeze@reddit
Honestly the consequences of a Gantt chart existing are always worse than accidentally having one long chain.
Your senior devs should be identifying high risk parts of the project and prioritizing them to happen before the last responsible moment. If they can’t or won’t do that, the project is already doomed.
For Gantt to work you’d have to send Cal Newport (deep work) in a Time Machine back to 1980 and also make everyone actually listen to Eli Goldratt.
In reality sequential items always slow down the most. They always but task 8 as starting the day after task 7 is due, which is fucking asinine. Each item that doesn’t get done on time results in a day for day slip of the project schedule. Each item that doesn’t get started on time due to bus numbers being overbooked or sick or on vacation, results in a day for day slip in the schedule. And in fact “day for day” is more bad estimation. It’s more than a day for each day.
Why? Because your employees responsibly scheduled vacations and doctor’s appointments to miss their commitments on the original schedule, and so now that it’s been rererererevised, some item with a very low bus number happens while they are out of the office either in body or in spirit (eg the wife is about to give birth and it’s a risky pregnancy, or their oldest is on a solo trip for the first time)
itijara@reddit
Gantt charts are a fiction but they do show the shape of a project. The problem is when managers fall in love with their chart and think it represents reality.
bwainfweeze@reddit
They always fall in love with their own charts.
Business people would make terrible drug dealers. They are always high on their own supply.
downthepaththatrocks@reddit
I've read a lot of 'Stop estimating' opinions lately and I'm gearing up to recommend our team stops doing it. Your article hasn't changed my mind, but I appreciate the counter-argument. You've helped me round out my thoughts better to account for both sides more thoroughly.
joelypolly@reddit
What I have found over the years is that people suck at estimating more because they don’t know what and how they will be building something than any inherent issue with the estimation process itself.
The people who are also really good at providing an accurate estimate also happened to be better at designing and building out the feature.
Personally I don’t know if removing the opportunity to practice providing an estimate and the thinking process is helpful in the long term for software engineers.
lunchmeat317@reddit
You can't estimate research. You can estimate well-known tasks.
If a problem has been done before - or if it can be broken down into various subproblems that have been done before - it's easier to estimate. If not, it isn't.
That is the core problem. People who are better at estimating, designing, and building, likrly a pulling from a larger toolset of known solutions. But problems that aren't well-scoped, well-defined, or well-known will always be harder to estimate.
bwainfweeze@reddit
You have to assign tasks to people who have never done them before or you will never have people who have done it before.
So even if I know exactly how to do this, I have to let Sam twist in the wind a bit before I save his ass because he won’t learn otherwise.
I don’t think it’s the estimation it’s the decomposition. It’s making the list of achievable tasks, which means you need to name tasks that -could - have a t-shirt size. There’s an old obscure pre-Agile Manifesto guy who claimed you only need to split tasks down to less than 2 weeks and you can leave it at that.
Scrum needs more because it’s trying to bin pack. It has artificial deadlines every two weeks. If you pull stories when the last completes you don’t need to do any of this other shit.
downthepaththatrocks@reddit
It's a valid concern. If anything though we over-refine. The team have gotten so good at vertical slicing and keeping things small now that the difference between a 1, 2 and 3 is just noise. We might just as well make everything a 1.5 and planning/velocity will remain largely unaffected.
lampshadish2@reddit
The estimates themselves might not be worth much, but the conversation that comes out of storypointing is invaluable. So even if you stop doing estimates, try to keep having those conversations.
OnlyForF1@reddit
In my team we revolve the story around "is this the minimal unit of work that would deliver customer value"
bmamba2942@reddit
This is how I feel as well. I always tell my team and others in the office that the final value agreed on for a ticket isn’t the real value but the discussion about the work is. Getting multiple perspectives on the work and answering questions or correcting assumptions about it is where the real value lies in my, maybe controversial, opinion.
downthepaththatrocks@reddit
Agreed but this team gets that discussion through agreeing on the acceptance criteria. If anything, we over-refine tasks and discuss too much ahead of it going in to a sprint.
Mysterious-Rent7233@reddit
I don't think the poster is the writer.
01homie@reddit
The business side will still depends on estimations to do many things. If you stop giving estimations, even if the business team acted like no problem, they'll likely just replace them with their own guess.
There's nothing unique about estimations in Software, it's the same for projects in all fields of Engineering.
BigBadamBoom@reddit
I wrote this last time this article was posted. The problem isn’t with estimates, sometimes they are necessary for random good (or bad…) reasons. Deadlines aren’t harmful all the time.
The thing is that SWE needs to do is expectation management. That’s the skill that can make or break a really great SWE, EM and so on. If you can manage your users expectations on when they will get whatever you are creating estimations don’t matter anymore as long as they are informed and the team is transparent about the good and the bad.
Piisthree@reddit
I think there are also many elephants in the room which make it even harder such as the pressure to align the estimate to the business. So, our quarterly marketing event is in 3 months and it would be great to announce something big there. What was the estimate for your latest big project to be released, 3 months or so?
bwainfweeze@reddit
I think Apple gets a lot of shit for demoing things that aren’t done for another two months but they’re probably right.
NotGoodSoftwareMaker@reddit
Ive often found that estimating software is relatively easy. Look at the feature, add about 50% more for safety and other interruptions, say no to all adhoc work and run with it.
The hard part is massaging your work into the fifty different formats that your company expects, going through the ceremonies of stories, t-shirt sizes and then having group think because we dared to vote on a point other than 5 or a medium shirt size.
Then we need to pretend that every developer works at the same pace. So further dumbing down is needed.
We then reschedule meetings because people havent read the design doc but they promise to read it next time.
We then pontificate on the difference between tasks, stories and epics.
Eventually after 3 months of refining a plan that was ready we can say that its time to work. By which point all initial estimates are out the window.
puterTDI@reddit
In regards to the design doc: your engineers should really be involved sooner. They shouldn’t first be seeing it after the design is done.
Brilliant-Sky2969@reddit
Or better, they should be part of the design process.
bwainfweeze@reddit
How can they? They’re behind in finishing the previous deadline. Don’t interrupt them with meetings! Well just tell them when we are done.
puterTDI@reddit
Very much agreed and is something I’ve been fighting and failing at.
Management wants it too but our pos absolutely refuse. We’ve made progress by getting them to sometimes do user stories and define the problem before telling us the solution.
I’ve gone so far as to say that u think the spec should stop at the user stories and engineers should take over and lead the effort to define the solution…mostly because I am confident we will actually be collaborative.
bwainfweeze@reddit
And that every dev has consistent output month to month. I don’t know how many times I’ve told people this will NOT be done by Dec 15, it’ll be more like January 15th if we’re lucky. It’s always the 10th to the 22nd. Always.
TheRekojeht@reddit
Fucking tell my boss that shit. I an DEVOPS and I fucking have to put up with Tableau and other shit constantly.
NotGoodSoftwareMaker@reddit
Ah i see. You have established yourself as competent, rookie mistake
h310dOr@reddit
You forgot that in between, spec changed, completely new features were added, others removed, and your team changed too. Oh and there's that new client who needs support, straight from the r&d team, and we gave them your (personal) number to make it easier / faster. Ah shift the deadline? Of course not, you just need to multitask. Ah and about the fact that we promoted you TLM, nah we are not going to hire a new engineer, I mean, you can do technical work full time, you are a tech lead right. Management is natural and organic after all. Right ? Okay thx, see you next week for the delivery. What do you mean we could have finished three time during these 3 months of meetings ?
ysustistixitxtkxkycy@reddit
IMHO the best ever approach I've read regarding software estimation is to track the estimate for every task as well as actual completion time in the ticket system and then use ML to convert a project schedule into an estimate based on historical data.
That said, the reality in much of the sector is that detailed and thoughtful estimates are used by top-down-managers to cut essential parts of the product and pressure ICs for the consequences of riding roughshod over their estimation work.
Excellent-Cat7128@reddit
And if you don't want people to feel like they are micromanaging their time, just use turn-around time (maybe from when ticket moved into "doing" and then when it was merged, or some other set of fenceposts).
As I said in another comment on the topic, I find it a bit strange that so many engineers are abjectly opposed to solving this problem. Yes, estimates are hard. Yes, they will be wrong almost by definition some percentage of the time. Yes, unknowns appear. But there are all sorts of programming problems that have exactly these issues. We depend on unreliable networks, weird cache behavior, and the weirdest and least predictable element of all: the user. Our whole job is to figure out how to wrangle that complexity and those unknowns to make good working software. People even have a lot of fun doing that.
I think what it comes down to is your second paragraph. Estimates become a data point that can be used against you by meddling managers and corporate types. I don't think that means the problem isn't worth solving. I think it means that political battles need to be fought.
I've always tried really hard not to let a lot of details leak outside my team. Other departments don't need to know velocity or number of comments on PRs or best and worst performers by completed ticket count per sprint. That data may be useful for the team if taken in context and used to inform rather than to decide. But I absolutely do not trust sales or ven the CTO to use that info for good, even if they intend to. If teams are able to control the info that goes out and set expectations appropriately, everyone is happier. It's hard to win that battle though.
ysustistixitxtkxkycy@reddit
Spot on. The entire idea of managing software like a production line, with arbitrary hard deadlines instead of a tracking towards quality level worth releasing is a huge mistake, a classic example of multiple layers of management engaging in a McNamara fallacy and focusing on what is easy to measure as opposed to what is important.
Excellent-Cat7128@reddit
Hard deadlines are going to exist sometimes, though. The example I used previously was software for a school system. Schools have fixed schedules. If they intend to use software for a semester, they need it to be ready before the semester starts. And if it won't be ready, they need to have an alternative in place. It wouldn't be acceptable for a software company to say "it's ready when it's ready".
In those cases, the analysis should change (but often does). There's a hard time constraint, but that doesn't mean other constraints are hard. Features can and should be negotiated. Maybe some features can actually be delivered after the hard deadline because they are not mission-critical. The features that are strictly required can be prioritized. But this requires communication and compromise, which are often not to be found when sales and CEOs are running the show.
bwainfweeze@reddit
If you can’t beat the hard deadline by a country mile it might not be worth taking on in the first place. School years and Christmas are known years in advance. Maybe you should have started three months earlier.
I don’t recall if it was me or my younger sibling but I know one year the last week of school their was shit piled up near the parking lot for some work to be done on the school during summer break. They started that project way before the end of the school year. They had a plan and they ordered materials, and they sacked those materials up ahead of the day they were needed. I think I can safely assume a company that does that also acquired people to do the work ahead of time as well.
ysustistixitxtkxkycy@reddit
While I think this is a solid example, I prefer to think of any feature that has a hard deadline as a bug-type ticket. This allows for streamlines prioritization of anything that truly must happen by a specific date, as opposed to attempting to solve the much less defined problem of "this bucket of features and improvements should be at quality by that time, let's get a lot of stakeholders into conferences to discuss priorities and potential schedule impact"
Excellent-Cat7128@reddit
Can you explain more? Let's say you are a startup and need to deliver an LMS to a school district in two years. It is going to be a bucket of features at a certain quality. It's going to start out as a less defined problem. How do you make it work?
ysustistixitxtkxkycy@reddit
The hypothetical problem here is the (sorry, before first coffee) problem.
A startup which hasn't shipped anything yet would not have a hard deadline for a project such as this - no customer depends on it, and a prospective customer might still change their mind.
They would in all likelihood aim for a minimum viable product and attempt to get the customer to accept it soonest, and then follow ticket based updates if there is a need for change.
bwainfweeze@reddit
Political battles against people who studied politics to the exclusion of other things. So it is what it is and we don’t want to “solve” it because it doesn’t stay solved. Every year there’s a fresh batch of confident idiots to argue with.
ArcanePariah@reddit
Yeppp. Basically Goodmans law in action. People are treating estimates as commitments which are the used to judge performance. So naturally engineers who have no political power react in a predictable manner to protect themselves, either avoiding any estimates or factoring in EVERYTHING including the part where their estimates are negotiated down by a large amount by business side. Which of course just makes business overcompensate more.
I really, really wish Mythical Man Month was mandatory reading for any engineering manager and even for product people.
bwainfweeze@reddit
The burn-down/-up chart already does this for you. Where it falls down though is the same place ML will fall down - the middle of the graph always has the highest slope. Early tasks and final tasks are always slower than average. You get an S curve every time. That inflection point is hard to predict and it says a lot about the delivery date.
Lothrazar@reddit
Does this get reposted once per week or every month? Hard to keep track
needlework_the_way@reddit
You could estimate 1-4 times a month, but maybe you should ask a different question to open up dialogue.
bwainfweeze@reddit
Opening dialog does make you look smart in front of your toadies though.
bwainfweeze@reddit
I’ve been doing this for thirty years, and having this argument for 28 of those. So yes, we’re gonna have this fucking conversation every month until it stops.
I really miss those first two years. Man were those good.
abundant_singularity@reddit
A word of advice always add 20-30% cushion
bwainfweeze@reddit
Parkinson’s law and Hofstadtler’s always conspire to fuck you no matter what. The buffers always get double spent and then some.
Early in the project someone sees a problem that really bothers them. They know there’s buffer and they think it’s worth spending on this thing. They overengineer it, plus they underestimate how long it’ll take. So now you’re already behind before the real unknowns show up, which you were supposed to have that buffer for.
The architectural astronauts are the worst at this. At least when I “overengineer” (air quotes because it’s feedback not my opinion) something, I’ve picked a source of variability that has already caused problems and will continue until after we deliver. I’m saving us two hours a week until the project is done, or reducing rework. Rework is especially bad because it costs the team political capital and face. Once people don’t respect you everything gets harder. So make sure you don’t ever end up looking like a bunch if fuckups.
CodingRaver@reddit
Estimation on legacy with unknown unknowns is making me want to quit
RGBrewskies@reddit
your first ticket should be a research spike, to learn what you need to do.
Give me six hours to chop down a tree, I will spend the first four sharpening my axe - Abe Lincoln
bwainfweeze@reddit
The spike is also friction that raises the minimum cost of everything. It helps them to stop practicing death by a thousand cuts by asking for a hundred piddly little things and instead ask for four serious ones.
etcre@reddit
Let's do it together.
Take this black box and make it work in another black box. How long will it take?
CodingRaver@reddit
Don't forget about the other black box you didn't know you needed to care about
wobfan_@reddit
idiots at mckinsey forgot to alter the numbers slightly so that it isnt immediately obvious that their sample size was a whopping 3
bwainfweeze@reddit
Maybe it was six. You don’t know!
Critical_Run_3303@reddit
How many times is this going to be posted
bwainfweeze@reddit
Until we stop having this conversation.
versaceblues@reddit
High level estimates with error ranges are fine... but my problem is that every few years some numbskull in leadership tries to "fix estimation" and overthinks a ton of process to make it "more accurate".
In the best case this process just doesn't work, and eventually ends up being dropped. In the worst case they introduce a TON of bureaucratic work and meetings that actually lower overall productivity.
Honestly I think most projects can be broken down into 2 categories:
You have a strong external pressure, that forces a fixed deadline. (ex. a confrence, a customer promise, an app that is tied in with a movie release). In this case accurate estimation doesnt really matter. You are going to need to work back from the deadline, and make it whether that means cutting scope or working more hours.
You have no external pressure. Your deadline is not fixed. In which case leadership should just timebox customer milestones, and keep developing until something useful is created. This is a good time to build an MVP then keep incrementally experimenting and delivering features.
In neither of these situation is accurate estimation super important.
bwainfweeze@reddit
“You made a commitment”
I fucking hate that guy. If I knew where his care was parked I’d let a little air out of his tire every day.
coldfeetbot@reddit
Nah dont do it. Estimations cause a shitshow. Either you dont meet expectations because you underestimated, your manager is upset with you and you become stressed and disappointed, or you overestimate amd your manager thinks “is that seriously going take you a whole sprint? Are you that slow?”
So yes, estimating is hard and costly. And thats time you could have spent working or resting instead. An alternative that works well is defining a backlog, prioritizing tasks and tackling them by priority.
bwainfweeze@reddit
I had a cynical boss who thought estimates were bullshit but the fact that they are isn’t understood by the people who make decisions. Once the decision was made, the truth trickles out, but the executives are already committed so they have to find the money to do it.
Basically he thought like a politician. If they knew how much it would really cost up front they would vote against everything.
I really didn’t like his attitude but it does line up awfully well with my experiences. I’ve never actively used it but I’ve kept my mouth shut and nodded along a few times while someone else was selling something we really needed to do no matter how long it took. I could already predict what would happen later.
RGBrewskies@reddit
youre estimating wayyyyy to granularly.
If you cant put a task into "easy, medium, hard, really really hard" -- you dont understand the task enough to work on it.
coldfeetbot@reddit
The less granular the better, I agree. But lets go further, why not focus on priorities instead? Yeah I can spend 2 hours reviewing all the tickets with the team to assign them an arbitrary difficulty rating, and what? If I tackle the easiest tasks Im going to be quick, but are they the most prioritary? If I tackle the most prioritary tasks first, then why spend time estimating if Im going to do this anyway?
LossPreventionGuy@reddit
prioritizing work is the pm's job. WTF is going on over there bro
PersianMG@reddit
I've never really seen estimates work in reality. The problem is the amount of time it takes to complete project is decoupled from deadlines. The best approach is to say look we can try to deliver X by this date and have regular refinements and communication with stakeholders as you go. This means moving up and down the timeline constantly and possibly cutting / adding scope based on performance. Obviously big buffers help.
tl;dr don't waste time estimating, spend time doing and constantly reevaluating / communicating
bwainfweeze@reddit
I think estimates are working - as best they can.
The problem is that management doesn’t understand the “best it can” part. I’ve had managers who do understand this, and they were liked by their employees but often not so much by their managers, who want guarantees in a world where nothing is guaranteed.
Brilliant_Smell_9340@reddit
this scene from mad max 2 feels familiar. https://www.youtube.com/watch?v=WD9NM0G0F-w
Independent-Rule-462@reddit
I am new to the IT industry. Although, not new to business and estimating projects. I believe the best way to estimate any project is to explicitly write out what is included and what is not (if needed). I understand my production rates. Meaning think about what you can and can't do in a particular timeframe. Then add some extra time to that, maybe 20% and use that as your estimated timeframe. The additional 20% should provide a little extra time for completion if you run into an issue. Update the boss or customer regularly, cross your fingers for good luck and go for it!
I did read you article and found it very informative. Thanks for sharing
pa_dvg@reddit
Don’t estimate anything that isn’t going to be done soon. Re-estimate stuff that went on the back burner but you’re going to do soon.
Use story points. They’re abstract enough to have some wiggle room but concrete enough to be useful for getting an amount of work right in a time period.
Make the number bigger if: * you’ve never done this before * you have external dependencies * it has a weird design that we don’t have established paradigms for * you did work like this before and it was hard, and you haven’t don’t anything about it so you can assume it will still be hard * it involves any odd rarely used components * you don’t have good tests or other controls * there’s known tech debt impacting the work * you require approvals / buy in from a scarce resource like a dba * you need to raise the level of abstraction to avoid complexity
Make the number smaller if: * it’s rote framework stuff you’ve done a lot of * it’s a part of the code you are really familiar with * it can be done entirely on team * it uses established ui patterns * you’ve done work just like this recently and it went well * it has all the tests and support you could possibly want to work safely
wildjokers@reddit
This article is just an article announcing that the next article will tell you how to estimate. Worthless and annoying.
It is impossible to give accurate estimates anyway, no one has a crystal ball. I have never heard anyone claim to be good at giving accurate estimates. Unforuatenly the author doesn't give any details. (apparently the details will come along in later posts which I will never see)
-grok@reddit
Software estimation just takes a little bit of empathy to figure out what estimate management wants.
You should push back a little so they feel like they won something, maybe moan and cry a little too if you are bucking for promotion.
BarelyAirborne@reddit
Estimates are great if your work load and objectives are fixed. They're never fixed though. There's always a rush job getting in the way, distractions cropping up, and specifications changing like the wind. I like to take my guesstimate and double it, unless the specs are fuzzy, in which case I quadruple it.
Best_Kaleidoscope_89@reddit
The hardest part isn’t usually the estimation but that they want it to match customer cost and deadline expectations. A 7 day task takes 7 days even if the customer only wants to pay for 5. So they put down 5 on the JIRA board and we go 2 days over if we do it properly. Alternatively they pressure some poor dev to do it 5 and end up shipping buggy spaghetti code that ultimately takes 8-10 days by the time someone has cleaned it up and fixed the bugs etc.
snipe320@reddit
😪 lame repost
BadKafkaPartitioning@reddit
srona22@reddit
So in short, if you can't estimate, split into smaller tasks, estimable. Even if still can't, just be sure to notify your client/manager/team lead, as soon as you found out blocking issues.
And as usual, blog post will be serial and some even making books out of topics, with "examples".
Excellent-Cat7128@reddit
Or just increase the error bars on the estimate. For people who can't handle that, the estimate can be communicated as the worst case by the error bars. That is, if you estimates 4 weeks, plus or minus 3 weeks, the reported estimate can be two months. At one job, I refused to estimate with a granularity of less than a quarter. Sales and marketing could then report out worst case scenarios and then we could deliver early sometimes and everyone was excited.
FullPoet@reddit
https://www.reddit.com/r/programming/comments/1f9bjr5/software_estimation_is_hard_do_it_anyway/
reddit-the-cesspool@reddit
Yeah this sub is crap. Same reposts or clearly promotional blog posts or AI spam.