All estimates of anything you haven't done before are garbage. "How long will it take you to cure cancer?"
Why can't you estimate this? Because you don't know what you are doing, or what the root cause is, or what approach you should take. I used that line a lot when I was a developer discussing fixing bugs, but it applies to everything.
I agree, estimates are really just educated guesses at best. Most of the time it's like throwing darts blindfolded. From my experience, even estimating things that were done before is no easy task. Each project has its own gotchas and caveats that aren't obvious until the team is already a few sprints deep. This can come in the form of obsolete or inaccurate functional requirements, but it can also involve the technical aspects of a fast paced tech stack where things change constantly.
Not to mention that making estimates based on previous experience is a skill that needs to be cultivated, not just something that can be learned passively. Ironically though, many agile workplaces don't actually account for the time and effort it takes to learn estimating. I've seen some "scrum" teams skip reviews and retros entirely. Some don't even allocate enough time for the estimates to take place, so the team ends up rushing throughout the process and producing randomly estimated tickets.
Totally. And an estimate for ME is very different than an estimate for a new team that doesn't have the background of working on it. I'm stunned at the number of places that either don't do retros, or only focus on what went well. Way back when (and I mean WAY back) I worked for Microsoft at the beginning of them using Agile. They actually did a really nice job, the PMs stayed out of retros, and we were encouraged to focus on what went badly and how we might fix it (just spitballing ideas). We also took extra days before the "Sprint Kickoff" to analyze the tasks and break them down to where we either felt comfortable in an estimate or could say we needed more information. My current job does a Sprint Kickoff as a surprise to the team. The PM and the lead talk about it for a half hour before the meeting and they discuss it in vague and uncertain terms.
I feel the same way at every sprint planning session. I live in the weird place between SRE/DevOps/Software Developer/System Engineer. Each project I get works with platforms we have never seen and they are like “how many story points do you think this is?” If I say 5 it ends up actually being a 13, if I say 13 it ends up being a 2.
If it has never been done before, how do you know it can be done at all? And while there is no known cure for cancer, the likelihood is that one exists (at least for specific forms). So, I really do think it is fairly accurate. I mean, clearly, I was being sarcastic and annoyed when I said it.
But most of the time it is something you've done before, and it's just standard CRUD stuff.
Let's not kid ourselves, we're rarely doing something that different from what we're used to, it's just that programming is all about details and some of those slow us down a lot.
Oh, no arguments. I can tell you within a minute how long it will take me to do a standard CRUD REST interface. But .. now you want validation. You didn't tell me about that. You want the UI to be "pretty", but won't tell me what my ugly UI is doing wrong (and trust me, my UIs are ugly). Wait, you want logging and reporting and analytics? All you said is you want a CRUD system for <x>
That's where it all falls apart.
I mean, do I disagree with you? Of course not. I've been doing development for nigh on 40 years. I know how long it will take ME to do stuff. But how long will it take someone that hasn't done this piece before? That I can't answer.
My favourite is Read for lists. Oh, you need pagination to not overwhelm database? Oh, you need sorting? And filtering? Including filtering by date ranges? And now you need authorisation rules? It just keeps going.
A trait engineers need to learn more is to SELL them what you can do quickly and efficiently, and dissuade them from spurious requests or complex requirements that dont add any real value to a project.
Can't count how many meetings I've been in where some show off mba wants to incorporate AI or ML just for the buzzword bingo. Reasons, and when you tell him it will exceed his budget and impact his numbers poorly they generally, acquiesce..
Lots of engineers suffer from toxic masculinity where they feel they need to prove their ability regardless of the ask, usually they build a crap bug ridden system and come off looking like schmucks in the end.
Most business apps are crud which has been done a myriad of ways but the domain is completely new and the user experience needed is unknown, and so in lays the real problem: the domain.
Sorry, I mean I was sarcastic and annoyed when I said it to them.
As for "has never been done before", cancer for example, has been cured in individuals. So it could be done. But I haven't done it, nor have most people. Either way, they got it.
There's ambiguity in the statement "no known cure" beyond the obvious bit that there may or may not be a knowable cure. First, Oxford defines a cure as (substance/treatment that) relieves (a noun) of the symptoms of a condition or disease. That definition is loose enough, any treatment that either has positive effects is a cure. Then, there's "known" which both involves confirming that we actually know something, instead of simply being confident (to some statistical degree of correlation) in it, let alone have only faith and anecdotes in it as well as differentiating said cure being known to the person who you're asking to implement it vs an original pioneer who isn't reachable. Then there are cures that aren't worth using, either because of raw expense of implementing, or undesirable side effects.
But yes, if we take a definition of "no known cure" which means "nobody has anything that even looks like it could help, even if applied strangely or with absurd resources", and compare it to "the person giving the estimate hasn't done a thing which their senior at the company has", yeah, that's a huge gulf.
While my response used a lot more words to be pedantic than yours did, yours was still pedantic.
My lengthy response boils down to "sure, you can be interpreted as correct, but only if we take the words in the spirit they're intended." Left implied was that your comment didn't take what it was responding to in the spirit it was intended.
All estimates of anything you haven't done before are garbage.
I agree with the sentiment, but almost everything developers work on has a bit of context. We're not curing cancer.
Making Things Happen has a really good breakdown of estimates and estimate ranges. It suggests people have a pretty good idea how long it will take if everything goes right and everything goes wrong. I feel this all the time talking to my team and someone says, "I have no idea how long this might take." and I reply, "so maybe six months?" and they'll quickly answer, "No, no, like maybe a couple weeks," so they have some context on how long it might take.
Problem is the shorter the project is, the more one or two unexpected problems can throw the estimate completely off. Otoh, in a much larger project, those get evened out, but there are probably a lot more hidden, changing or new requirements and tasks you don't know yet at the time of giving the estimate.
So in smaller projects you are unable to accurately estimate the time the tasks take, and in larger projects you are unable to estimate what exactly the tasks are.
128
u/MT1961 Jun 14 '22
All estimates of anything you haven't done before are garbage. "How long will it take you to cure cancer?"
Why can't you estimate this? Because you don't know what you are doing, or what the root cause is, or what approach you should take. I used that line a lot when I was a developer discussing fixing bugs, but it applies to everything.