5 ms·

Let's put it this way, then - either you're totally incapable of building whatever we're talking about under any circumstances, or, even if it has unknowns, the

Let's put it this way, then - either you're totally incapable of building whatever we're talking about under any circumstances, or, even if it has unknowns, there are steps you can take in the right direction to get started and move things along. You will learn things that will help you understand the problem better along the way. If it's the latter case, then a good developer can describe the immediate steps they'll take and what questions they expect to answer. Whatever the case, there is always some concrete next step you can take to which you can assign a reasonable estimate of time. That might just be that you'll spend one day perusing some documentation, and the only outcome you expect from that is that you'll develop a reasonable enough understanding of how large/complex the documentation is, such that you can come back with an estimate of how long it will take to find and carefully read all the relevant sections of the documentation. That's totally fine - if it's the sort of wildly unknown problem that you're describing, then I recognize we'll have to take steps to understand the problem. There's still never a case where it's impossible to create an immediate plan of action and understand roughly how long that will take (unless you are simply unqualified to take on the problem). I had a boss loved the phrase, "a date for a date." He just meant that if you can't give me a date for when the thing will be done, then you need to give me a date for when you can give me a date for when the thing will be done. Can't do that? Date for a date for a date. However many levels we have to go, you're not getting out of whatever meeting we're in until you can give me a date by which you'll be able to come back and give me another date.

myshpa 4y ago
> I had a boss loved the phrase, "a date for a date." I love deadlines. I love the whooshing noise they make as they go by. - Douglas Adams
jiggawatts 4y ago
The problem is that in programming the discovery part is often 90% of the task. There can be situations where there is no 10% discovery phase and the rest of the time we’re banging out predictable code. Right now I’m replatforming a legacy app. It’s undocumented, developed by dozens of staff — all of whom are gone, and full of crazy bugs and gotchas. Out of the box it wouldn’t compile, the source code was missing files, etc… The task is to find every such hidden issue, fix it, which then allows us to find the next hidden issue, and so on. When we’re done finding issues, we’re basically done. Can you tell me how many issues we’ll encounter? I can’t. I’m being perpetually surprised by the code base, finding random binary blobs that actually are from some other project we didn’t even know exists until that moment. Fundamentally, it’ll take as long as it takes. The application is mandated by law, and it must be made to work. It’ll cost what it costs, and it’ll be finished when it’s done. Instead of begging for estimates, a good manager would be bending over backwards to accelerate the process. Get in the original devs for a week under contract. Procure tooling that helps find bugs faster. Instrument the source servers to get better comparative info. Etc… I’ve never seen that occur. It’s always just the same question repeated over and over as if that can make the unknown known.
- bluesnowmonkey 4y ago
  > The problem is that in programming the discovery part is often 90% of the task. That's exactly it. Scoping out the solution is 90% as hard as just doing it. By the time you've figured out enough of the details that you're sure there are no more surprises waiting... you're just about done. I suspect that a lot of counter-examples people have witnessed are examples of poorly factored codebases. I've seen teams/projects where they estimated projects accurately because the "new" thing being created was a slight variation on a kind of thing they'd created many times. For example, I once worked for a company that generated e-commerce sites for clients. They'd make a new one basically by copy/pasting an existing site from another client and changing some text/images here and there. Super predictable after doing this a bunch of times... but also a maintenance nightmare having dozens of slightly different codebases. And how do you iterate? They couldn't evolve. Shopify ate their lunch. I bet Shopfiy has a really hard time estimating the time to ship a new feature. But they add it once for everybody.
firstlink 4y ago
When the discovery process is iterative, there is never a point at which you have an estimate for the whole task. Each new discovery step may be the last one or it might lead to more steps, and you won't know until you complete some step, look for the next one, and realize the project is done. A knowledgeable developer can predict how this cycle goes and explain that an estimate of the whole task is impossible, and they will be quite literally and completely correct in that case.

myshpa 4y ago

> I had a boss loved the phrase, "a date for a date." I love deadlines. I love the whooshing noise they make as they go by. - Douglas Adams

jiggawatts 4y ago

The problem is that in programming the discovery part is often 90% of the task. There can be situations where there is no 10% discovery phase and the rest of the time we’re banging out predictable code. Right now I’m replatforming a legacy app. It’s undocumented, developed by dozens of staff — all of whom are gone, and full of crazy bugs and gotchas. Out of the box it wouldn’t compile, the source code was missing files, etc… The task is to find every such hidden issue, fix it, which then allows us to find the next hidden issue, and so on. When we’re done finding issues, we’re basically done. Can you tell me how many issues we’ll encounter? I can’t. I’m being perpetually surprised by the code base, finding random binary blobs that actually are from some other project we didn’t even know exists until that moment. Fundamentally, it’ll take as long as it takes. The application is mandated by law, and it must be made to work. It’ll cost what it costs, and it’ll be finished when it’s done. Instead of begging for estimates, a good manager would be bending over backwards to accelerate the process. Get in the original devs for a week under contract. Procure tooling that helps find bugs faster. Instrument the source servers to get better comparative info. Etc… I’ve never seen that occur. It’s always just the same question repeated over and over as if that can make the unknown known.

bluesnowmonkey 4y ago
> The problem is that in programming the discovery part is often 90% of the task. That's exactly it. Scoping out the solution is 90% as hard as just doing it. By the time you've figured out enough of the details that you're sure there are no more surprises waiting... you're just about done. I suspect that a lot of counter-examples people have witnessed are examples of poorly factored codebases. I've seen teams/projects where they estimated projects accurately because the "new" thing being created was a slight variation on a kind of thing they'd created many times. For example, I once worked for a company that generated e-commerce sites for clients. They'd make a new one basically by copy/pasting an existing site from another client and changing some text/images here and there. Super predictable after doing this a bunch of times... but also a maintenance nightmare having dozens of slightly different codebases. And how do you iterate? They couldn't evolve. Shopify ate their lunch. I bet Shopfiy has a really hard time estimating the time to ship a new feature. But they add it once for everybody.

firstlink 4y ago

When the discovery process is iterative, there is never a point at which you have an estimate for the whole task. Each new discovery step may be the last one or it might lead to more steps, and you won't know until you complete some step, look for the next one, and realize the project is done. A knowledgeable developer can predict how this cycle goes and explain that an estimate of the whole task is impossible, and they will be quite literally and completely correct in that case.