3 ms·

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 th

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.

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.