[setr]

It is very rare that we actually work on something truly novel, and it’s even rarer that the majority of the task/project is novel. It’s really not that hard to identify something “reasonable” for most tasks, once you’ve broken it down. The pieces that are actually novel — you make an estimate to produce an estimate (how much work do you need to do before you get a handle over it?)

Of course, the further you go out, the more your error margins (and the less others naturally rely on your estimate, and the more likely you say something generic like coming soon in 2025)

But this notion that it’s all creativity born of the ether, as if you’re sitting around waiting for eureka to suddenly strike is complete bullshit.

There is the issue that external resources will latch onto your vague estimates like it’s the word of god, and try to hold you accountable to unreasonable degree, but that has nothing to do with your planning. Usual solution there is to figure out what feels reasonable, and then double it again for your boss — and double it again for the client (which you’ll probably lose a bit to negotiation). There’s also the issue that a single heisenbug can take stupid amounts of time to resolve… but that’s why you doubled up — you keep buffer for that kind of thing.

The vast majority of any project is just plumbing — creative or not.

[makeitdouble]

You are of course right, and that’s the basis of SCRUM like thinking.

The point I’d still raise is that very few organization are OK with actually going the full length to reduce the error margin to what they want to tolerate (they still end up eating the costs associated with the actual execution time, of course)

For instance: you integrate a new API from a new vendor, and a request is made on a time estimate. It’s probably a very bland task with no crazy thinks to do, except you have no idea what surprises you might get actually running the API. What if the vendor din’t account for one of your use case for instance ? (let’s say they round money amounts to the nearest cent while your business requires round ups everywhere instead)

The safeguard against that risk is to either: fully run the API beforehand and cover all your use cases, or document every single requirement and run them through your vendor. If you’re not a bank nor the NASA, you probably won’t be allowed to do that before giving an estimate that will set a deadline.

It’s to me one of the reason why outside I put “creative” in quotes, as the problems we’re trying to solve don’t need to be complex, unexpected is sufficient. And ‘deadlines’ are more probably more ‘guidelines’ as most orgs don’t really care to secure them.

[laserlight]

> It is very rare that we actually work on something truly novel

I'm working on something truly novel to me every day. The fact that it's novel to me is enough to make any wishful planning arbitrary.

[hef19898]

Unless you are really bleading edge, say mRNA vaccines, there should be someone with experience in what you are doing. Even for the bleading edge stuff, people have relevant experience to build upon.

[laserlight]

Sure, there are people who are experienced in the areas that are novel to me. But, engaging them to the project may not turn out to be a better alternative (in terms of all kinds of variables: time, money, communication and coordination overhead, etc.) than my learning the subject.

[harveywi]

Teams that subscribe to the agile methodology have a tendency to churn out ad hoc systems because there is not time for due diligence. The end result is ad hoc things built on ad hoc things. There is no limit to the learning curve. The knowledge doesn't transfer in the smoothest way because (a) there is no time for an engineer to perform due diligence, and (b) engineers are interchangeable cogs that flip high tech burgers based on orders from the Jira board.

The amount of brain waste caused by agile is immense. So many minds toiling away, trying to pick apart some long lost engineer's cleverisms and build something mundane on top of them.