The whiteboard marker squeaks-a high-pitched, mocking sound that vibrates through my teeth-as I draw a box that is supposed to represent three months of my life. Around the table, 7 pairs of eyes track the movement of the plastic tip. There is a specific kind of silence in a boardroom when a project manager is waiting for a number. It is the silence of a vacuum, waiting to be filled with a commitment that everyone in the room knows is a fiction. I just realized my phone has been on mute for the last 47 minutes. There are 17 missed calls, but for some reason, the notification light only blinked 7 times. It is a tiny, localized catastrophe that perfectly mirrors the larger one happening right now in this conference room. We are about to commit to a date for a feature that hasn’t been fully defined, using a technology we only started learning 27 days ago.
“Three weeks,” I say. The words feel heavy, like stones I’m dropping into a well. I know it’s at least 37 days of work, maybe 47 if the API documentation is as bad as the last time. But three weeks is what the spreadsheet wants to hear. My manager leans forward, his chair creaking. “Can we do it in 17 days?” he asks. I feel the familiar itch of a lie forming. I look at the 7 empty coffee cups on the table and nod. Sure. Why not? We’re already living in a fantasy world; we might as well make the dragons bigger.
The Illusion of the Factory Floor
Software development is often treated as if it were a factory line. We talk about ‘velocity’ and ‘throughput’ as if we were stamping out steel fenders for a 1957 Chevy. But building software is not assembly; it is discovery.
It is more like writing a 700-page novel where the plot changes every time you reach a new chapter. You cannot estimate how long it will take to have a brilliant idea. You cannot put a timestamp on the moment a bug finally reveals its source after 17 hours of staring at a screen until your eyes feel like they are coated in sand. Yet, we persist in this ritual. We spend 27% of our time estimating the work instead of actually doing the work, a recursive loop of wasted effort that serves only to provide a false sense of security to people who don pink shirts and talk about ‘deliverables.’
“Certainty is the tax we pay for not being brave enough to learn.
Styling Time, Not Food
I think about Lucas H., a food stylist I met at a dive bar last year. He was sitting there with a gin and tonic, looking absolutely defeated. He told me he had spent 17 hours that day trying to make a bowl of cereal look ‘youthful.’ He used white glue instead of milk because milk makes flakes soggy in 7 seconds. He used motor oil to make a pancake look moist.
Styled Moistness
Appetizing Deck
Software estimation is the motor oil of the corporate world. It is the substance we pour over a messy, unpredictable, chaotic process to make it look appetizing in a PowerPoint deck. We aren’t styling food; we’re styling time. We’re making the future look more manageable than it has any right to be. Lucas H. understood that the final image was a lie, but it was a lie the client was willing to pay $777 to see. We do the same. We tweeze our Jira tickets like they’re sesame seeds on a bun, making sure they look perfectly aligned for the sprint review, while the kitchen behind us is actually on fire.
Instead of actually doing the work.
The Fear of the Unknown
There is a deep-seated fear of the unknown that drives this obsession. In an industrial mindset, the unknown is a defect. In knowledge work, the unknown is the entire point. If we knew exactly how to build the thing, we would have already automated its creation. We are paid to solve problems that haven’t been solved in this specific context before.
We add a buffer of 27% here and 17% there, but the buffers always get eaten by the ‘unknown unknowns.’ Then, when the deadline hits and the code isn’t ready, the trust breaks. Not because we were slow, but because we promised a certainty that was never ours to give.
The 17-Day Myth: Reality Check
Initial: 17 Days
The Spreadsheet Commitment
Actual: 67 Days
Legacy database discovery revealed 7x problems.
Precision vs. Accuracy
This culture of precision over accuracy is toxic. Precision is saying it will take 147.7 hours. Accuracy is saying it will take somewhere between two weeks and two months. Managers love precision because it fits into a cell in a table. They hate accuracy because it’s hard to build a budget around a range.
Fits in a spreadsheet cell.
The only thing that is true.
Pragmatism involves admitting that the map is not the territory. It requires a level of vulnerability that most corporate environments actively discourage. You have to be able to say, ‘I don’t know yet,’ without being treated as if you’re incompetent.
When you look at how custom software development approaches these things, you start to see the difference between a promise made to quiet a room and a strategy built to survive a storm.
The Hidden Cost of Pre-Solving
I’m currently looking at my reflection in the black screen of my laptop. It’s 7:07 PM. I should have left 57 minutes ago. I stayed because I felt guilty about that ‘three weeks’ estimate I gave earlier. I’m trying to pre-solve problems in my head to make the lie true. This is the hidden cost of estimation: the mental load of trying to force reality to conform to a guess.
A Partnership Built on Pull
It’s entirely unnecessary if you change the relationship between the business and the builders. Instead of a contract based on a fixed date, imagine a partnership based on continuous value. What if we stopped asking ‘When will it be done?’ and started asking ‘What is the most important thing we can finish in the next 7 days?’
“We are styling time to hide the mess.
I think about Lucas H. again. He told me that once, he tried to use real ice cream for a shoot. It melted in 7 seconds under the hot studio lights… But software isn’t ice cream. You can’t replace the core of your product with white glue and motor oil and expect it to actually function when a thousand users hit the login page. You can style the timeline, but you can’t style the execution.
The cycle continues.
I deleted the voicemails. The irony is that the recruiter probably wanted an estimate on when I could start. I should tell him I’ll be available in 27 days, just to see if he’ll ask if I can do it in 17.
Embracing the Mess
If we want to fix this, we have to start by admitting that we are all playing a game. The manager knows the estimate is a guess. The developer knows it’s a guess… We need to embrace the mess. We need to stop treating 37-page requirement documents like they’re sacred texts. They’re just lists of assumptions that haven’t met reality yet. The only real metric of progress is working code. Everything else is just a story we tell to sleep at night.
Known: Bakery Stop
Adds ~7 min
Unknown: Code Path
97% chance of delay
I’m going to go home now. I have 17 blocks to walk, and I estimate it will take me 17 minutes. But I know there’s a 97% chance I’ll stop at the bakery that sells those 7-layer bars, and that will probably add another 7 minutes to the trip. And you know what? That’s fine. The bakery is a known variable. The software I have to write tomorrow is not.
I’m going to stop lying to myself about how much I can control. Maybe tomorrow, when they ask me for a number, I’ll just tell them a story about a food stylist and some motor oil. It’ll be more honest than anything I’ve put in a spreadsheet in the last 7 years.
The lie doesn’t make you a bad developer; it just makes you a person trying to survive a system that values the illusion of control over the reality of creation.
Maybe it’s time to stop the squeaking marker and just admit that we’re all wandering in the dark, trying to find the light switch together.
