A few months ago, I wrote a post about organizational biases to ship frequently vs plan heavily. This post attempts to be a tangible follow-up on the concepts laid out there.
I recently decided to build a piece of custom furniture for my living room, a table to house a collection of music equipment, with flush-mounted gear, cable routing, ventilation, the works. I had never built a piece of furniture before. I set a goal date of May 16th. It is now June 2nd and I am not done. I haven’t mounted the top shelf. I haven’t done the brass inlays. I haven’t even applied the final varnish.
I tell you this not to complain, but because every single thing that went wrong maps almost perfectly onto why software engineers struggle to give accurate delivery dates, and why that struggle is not a failure of intelligence, discipline, or effort. It is a structural property of doing hard, novel things in the real world.
The Story
We Didn’t Know What We Were Building
It started with a Pinterest board. My partner and I went back and forth for weeks on Instagram saves and reference images, trying to land on a design. The problem was that her taste is excellent and expensive, and sometimes she doesn’t know exactly what she wants until she sees it. Several of the designs she was drawn to were either beyond my skill level to execute or would have cost as much as buying something custom-made. So the first delay happened before I had touched a single piece of wood: we spent weeks just trying to define the scope.
This is requirements gathering. It feels like pre-work, like it doesn’t count. It always counts.
The Architect Went AWOL
Once we had a rough direction, I brought in a CAD designer to model the cuts: tolerances, dimensions, wood depth, gear clearances, cable routing space. That took just over a week. But near the end of the process, I realized the wood depth in the design was wrong. I needed to change it from 19mm to 22mm. I asked the designer to update it. He went completely silent. No response.
So I had to do the math myself, manually, at the last stage of design, which is exactly when manual math produces errors. Errors I would not discover until much later, during assembly.
In software: your architect leaves, your tech lead goes on parental leave, the person who holds the context disappears. And the people who remain have to reconstruct it from first principles, under pressure, and introduce mistakes they won’t find until production.
The Vendor Took Longer Than Expected + an 11th-Hour Surprise
With the CAD files in hand, I went looking for someone who could supply the wood and CNC the cuts. I contacted multiple vendors across France, biasing toward those who could do both, since I don’t have a car and moving large pieces of lumber across Paris is not a simple thing. I spent a long time looking for walnut, and struggled to find it at a reasonable price The first several quotes came back shockingly expensive, close to what a fully custom piece built by a specialist would cost. So I ended up splitting it: Oak from a regional lumber supplier for the straight cuts, and myself for everything else.
Then the French holidays hit. Then, the day before I was originally take delivery, I was informed that the board size I had purchased wasn’t actually available due to an inventory error on their side. I had to send payment to cover the minor difference in cost, and naturally they wouldn’t start cutting until the transfer cleared, even though 95% of the cost had already been paid.
I didn’t take delivery of the wood until May 24th. My goal project completion date was May 16th. I hadn’t even started building anything yet.
This is third-party dependency management. The vendor has their own priorities, their own blockers, their own processes. Your project is not their emergency. And the surprises often come at the end of the wait, not the beginning.
The Wood Arrived Warped
When the lumber finally arrived, some of it was bent. Not dramatically, but enough that for a flush-mounted piece of furniture, it couldn’t be used as-is. Before I could sand or stain or assemble anything, I had to lay the warped pieces flat, stack heavy weights on them, and wait several days for them to straighten out.
This is environment setup. It’s the database migration that has to complete before development can begin, the infrastructure provisioning that blocks the sprint. It doesn’t show up in estimates because you don’t know it’s a prerequisite until you’re already holding the warped wood.
Some Cuts Were Wrong. Some Were My Fault. Some Were the Vendor’s.
Once the wood settled, I started verifying the cuts against the design. Two separate problems emerged. First, some cuts were simply incorrect. The vendor had made errors. Second, some cuts reflected errors in my own revised calculations, the ones I had done manually after the CAD designer disappeared.
Six or so pieces needed to be shortened. Others needed to be recut entirely.
In software, this is the difference between bugs introduced by a dependency and bugs introduced by your own team. Both require triage. Both require fixing. Neither was in the original timeline.
I Wasn’t Skilled Enough for Some of the Work
A diagonal cut I needed, precise, angled, critical to fit, was beyond what I could do reliably with the tools I had. So I took it to a local atelier and asked for their help. Their cuts weren’t precise enough either. Which meant I had to do extensive sanding later to compensate.
Then it happened again. A second trip to the atelier for another set of cuts that required more professional equipment than I owned.
Outsourcing a task because it exceeds your skill level is not always faster than doing it yourself badly. And it introduces a new dependency: someone else’s precision, schedule, and interpretation of your requirements.
We Didn’t Know What Tools We’d Need
Throughout the build, I kept discovering that I needed equipment I didn’t own. A specific router bit. A particular shank size. More clamps than I had bought. I was placing Amazon orders throughout the project, not because I hadn’t thought about tooling, but because the gaps only became visible as the work unfolded.
One order arrived with the wrong shank width, 8mm instead of 6mm. I went to a local hardware store to find the right one. They didn’t have it. And the reason I needed that specific size had itself changed: my partner had decided the original roundover was too small aesthetically, which meant I needed a larger one, which meant a different shank, which meant a trip to Amazon, a wrong delivery, a physical store run, and a stockout. One aesthetic preference, expressed mid-build, cascaded into four sequential delays.
This is scope change meeting supply chain reality. Neither is unusual. Together, they are brutal.
A Requirement We Couldn’t See Until It Was Real
We never intended to finish the interior of the piece. Interiors are hidden; you don’t necessarily need to stain and varnish what nobody sees. But once the design became concrete, we realized that the center section is meant to be removable, because I’ll pull out that instrument and take it to gigs. That changes things: an interior that gets handled, transported, and exposed has to be finished after all, which means more staining, more drying time, and a new worry about varnish scuffing during transport. It also opened a fresh question: do we need to build a lid to protect it? And I’m not even sure I have enough wood left to build one.
This is the requirement that is invisible on paper and obvious the moment the thing exists in the real world. Nobody was being careless. The need simply could not be seen until the artifact was concrete enough to reveal it, and by then it lands as new scope, new work, and a possible new material constraint all at once.
The Staining Took Much Longer Than Expected
Staining wood sounds simple. It is not. The right amount of sanding before staining, the right number of coats, the right product, we went through multiple attempts before we found something we were even marginally happy with. Then we decided we weren’t happy with it, bought a different stain entirely, and started again.
And stain dries at its own pace. You cannot rush it. Every coat requires waiting, hours, sometimes overnight, before the next step. None of this drying time was in my original estimate, because I had never stained anything before and didn’t know to account for it.
This is the testing and QA phase that always expands to fill whatever time is left, and then some.
My Partner Wanted to Help, But Couldn’t Always Be There
My partner was genuinely invested in this project. She had opinions, good ones, and wanted to be involved. But her schedule and my work windows didn’t align. There were decisions I couldn’t make without her input, and moments when I was ready to move forward and she wasn’t available to weigh in. So I waited. Or I made a call myself and checked later, which sometimes meant revisiting it.
A stakeholder who is engaged but unavailable is not a problem with a simple solution. You can’t force schedule alignment. You just absorb the cost.
Adding Help Didn’t Always Help
At various points my partner was able to join in, holding things, checking measurements, running to the hardware store. But the nature of furniture building meant that most tasks couldn’t actually be parallelized. You can’t sand a piece that’s still drying. You can’t glue pieces that haven’t been cut to final size. You can’t assemble until the parts are ready.
As Frederick Brooks observed, and as I can now confirm from personal experience: nine women can’t make a baby in one month. More hands on a sequential process don’t compress time. They distribute presence across a timeline that doesn’t shorten.
Every Time I Had to Pack Up, I Lost Time
We had friends over a few times during the project. Each time, I had to pack away all the tools, the sawdust, the works-in-progress. And each time I came back to the project, it took real time just to get set up again: remember where I was, lay everything out, re-establish the mental model of what came next.
Context switching has overhead. Every context switch has overhead. This is true at the workbench and it is true in a sprint.
But I Got Better
Here is the thing I didn’t expect: the longer the project went on, the more accurate my estimates became. The first time I routed a cable hole, I had no idea how long it would take. The fifth time, I could tell you almost exactly. My uncertainty collapsed as my experience accumulated.
This is the painful irony of novel work. The estimates are worst precisely when the stakes are highest, at the beginning, before you know anything. By the time you know enough to estimate well, most of the work is done.
Why Dates Are Actually Hard
The furniture project is a small version of what happens on almost every software project that involves meaningful novelty. The delays didn’t come from laziness or bad planning. They came from:
- Unknown requirements that only clarified through iteration
- Dependencies on third parties who operate on their own schedules
- Material and environmental conditions that couldn’t be anticipated
- Defects from multiple sources: some external, some self-introduced
- Skill gaps that only reveal themselves when you attempt the work
- Tooling gaps discovered mid-execution, not at the start
- Scope changes that cascade into unexpected downstream delays
- Sequential constraints that no amount of additional people can compress
- Stakeholder availability that doesn’t always align with work windows
- Context switching overhead that makes every interruption more expensive than it looks
- Drying time: the phases of work that just take the time they take, regardless of urgency
Any one of these would make a date hard. In practice, you get most of them simultaneously.
When Dates Are Actually Easier
Dates are not always impossible. There are two conditions under which they become meaningfully more reliable.
The first is repetition. When the work is well-understood, has been done before, and is being executed by someone with direct experience doing it, estimates are reliable. A contractor who has built the same cabinet fifty times can tell you with confidence how long it takes. The unknown unknowns are gone. The variables are bounded. The surprises have already happened to someone else.
This is why estimates are reliable for maintenance work and unreliable for new product development. Maintenance is mostly repetition. New product development is mostly novel.
The second is structure. When the work is genuinely new, dates become achievable, not easy but achievable, under the right conditions: a team that is fully dedicated and not context-switching across multiple priorities, frequent and honest breakdown of tasks into small verifiable units, and a willingness to re-estimate regularly as new information arrives rather than defending an original number made in ignorance.
This is the core premise of agile development, and it works when it’s actually practiced: not as a ceremony, but as a genuine commitment to surfacing reality early and adjusting.
The Tradeoff Nobody Wants to Name
Executives ask for dates on everything. This is understandable. Dates enable planning, coordination, and accountability. And here’s the uncomfortable part: dates for everything are possible. The reasons above make dates hard, not impossible — and difficulty can always be bought down with enough slack and enough people. What you can’t do is buy it cheaply.
Dates for some things are extremely practical. When something genuinely matters, you can commit resources to it, focus a team, and go as hard as possible to hit the date, with enough flexibility built in to absorb surprises. This works. But it only works because you are concentrating force on a specific target.
There’s a catch: if your team is already running at capacity, and you’ve committed hard to a date, then when something unexpected comes up (and it always does!) you will be late on something, because resources have to be pulled to honor the commitment. You cannot hit aggressive dates on everything simultaneously when you’re at capacity. The math doesn’t allow it.
This is exactly what creates the incentive to pad. Engineers and product managers learn that the way to hit a date with high confidence is to inflate the estimate. And padding works, for hitting the date. But it adds a severe cost to overall velocity. Every buffer added to protect a commitment is time the organization isn’t spending on actual progress. Do it across every estimate, on every team, and you’ve quietly cut your throughput in half while feeling more “predictable.”
So dates-on-everything isn’t impossible. It’s expensive — and the bill comes due in exactly that buffered throughput. For a handful of genuinely critical efforts, paying it is worth it: you concentrate force, absorb the surprises, and hit the date. For most of what an organization does, it isn’t worth it — you’d be paying a premium for certainty on work where being roughly right and fast would have served you better. That’s why dates-on-everything is the wrong default for most teams: not because the dates can’t be hit, but because hitting them everywhere costs more than the predictability is worth.
So at some point, you have to choose. As I’ve previously written, you cannot maximize both velocity and predictable dates at the same time. You can optimize for raw speed and accept that dates will be soft. Or you can optimize for reliable commitments and accept that you’ll move more slowly to fund the buffers.
Pretending you can have both is how you end up with teams that are simultaneously slow and late.
The Honest Summary
When an engineer tells you a date, they are making a guess about a future that depends on requirements that may change, dependencies that may slip, tools that may fail, and skills they may not yet have. The more novel the work, the worse the guess. You can buy a better guess — with slack, with focus, with people — but you can only afford to do it for so many things at once.
This is not an excuse. It is a description of the terrain.
The furniture is not done. I don’t know exactly when it will be done. But now I have a thorough metaphor for almost every reason why software delivery is hard to predict… and I built that understanding one warped plank, one wrong cut, and one missed delivery at a time.
Discover more from Wil Writes
Subscribe to get the latest posts sent to your email.