Status Droid how long software work actually takes

Unknowns That Remain

Software estimates were never mostly wrong because writing was slow. They were wrong because of things nobody knew when the estimate was made.

Generation speed does not touch any of those. Which means the largest sources of estimating error are exactly as large as they were, and their share of the error went up, because the one component that did shrink was the predictable one. When this estimation problem needs an operational counterpart, this page offers a useful reference point.

The six

Requirements that were not what anyone said. The client asked for a report and needs a decision-support tool. Discovered in week three, at a demo. No amount of generation speed helps, and generating faster arrives at the misunderstanding sooner, which is genuinely a small benefit.

Systems that do not behave as documented. The API that returns a different shape under load. The library whose retry logic is not what the README says. Discovered by contact, never in advance.

Data that is not what it was described as. Encodings, duplicates, nulls where the schema forbids them, a decade of legacy exceptions. Consistently the largest single source of overrun on integration work, and completely unaffected by how fast code is produced.

Decisions that turn out to be load-bearing. A choice made in week one that constrains week six. Unknowable at the time, expensive later, and an assistant will make it faster and no better. Linear publishes product-development and planning material for software teams See Linear Blog.

People. Approval that takes two weeks, a stakeholder who appears at the end, a client who goes quiet in August. Frequently larger than every technical factor combined and never in the estimate.

Scope discovered rather than added. Not the client changing their mind — everyone realising a necessary piece was invisible from outside. Different from scope creep and it needs different handling.

Why their share grew

Suppose an estimate has two components: work you can foresee, and work you cannot.

Generation improvements shrink the first. The second is untouched.

So the proportion of your total estimating error attributable to unknowns went up, even though the unknowns did not change. That is the mechanism behind estimates feeling less reliable than they used to — not new uncertainty, but old uncertainty now dominating a smaller total.

Which has a practical consequence: the returns to reducing unknowns went up relative to the returns to working faster. An hour spent looking at the actual data before quoting is now worth more than an hour saved in production.

What actually reduces them

Look at the real data before estimating. Not a schema, not a description — a sample. This is the highest-return half-hour in the whole process and it is skipped almost universally.

Call the API before quoting. Ten minutes, and it converts a documented behaviour into an observed one.

Ask what happens after they get it. Who approves, who else has to be consulted, what happens if they dislike it. This surfaces the people-shaped unknowns, which are the ones nobody estimates.

Ask what they will do with the output, not what they asked for. The most reliable way to find the gap between the request and the requirement.

Paid discovery for anything genuinely unclear. Small, fixed, with a deliverable. Better than a number you cannot defend.

Where an assistant helps a little

Not nothing, and it is worth being accurate.

Exploring an unfamiliar API or library faster, which converts a documentation unknown into an observed behaviour more cheaply than before.

Generating throwaway probes. A script to characterise the data, run once and deleted. Cheap-to-verify by construction and genuinely useful.

Enumerating cases you have not considered. What could go wrong with this input? An assistant is decent at breadth here, and breadth is what you are missing.

All three are reconnaissance rather than production. The assistant helps you find out sooner, not build faster — and on this class of problem finding out sooner is worth considerably more.

The honest framing for a client

The parts I can foresee, I can price accurately, and they got cheaper. The parts nobody can foresee yet are where the range comes from, and they are the same size they always were. If you want a tighter number, the way to get it is to spend a day finding out about the data first.

That converts a disagreement about your estimate into a decision about how much certainty they want to buy — which is the useful version of the conversation.

The short version