I'm a senior staff engineer at Sleuth, a SaaS observability platform (the first engineer they hired, de-facto architect), and the person who just gave this talk.
Almost two decades of building software.
Multi-tenant architecture. Circuit breakers guarding 2-3 million third-party API calls a day across about 40 external APIs. Real-time anomaly detection for hundreds of clients.
Python Go Django Celery PostgreSQL Redis RabbitMQ Elasticsearch LLM agents Conference speaking
LinkedIn is the fastest way to reach me.
Software estimation has turned into ritualized guessing.
We are pushed to estimate, but then we aren’t believed when we give high numbers.
It has been known since the 70s that developers tend to give very optimistic estimations. We give tight numbers because a small range makes us look knowledgeable, and managers ask because a number, any number, feels like control.
So I’ve come to think estimation was never really a maths problem. It’s a social one.
Unfortunately, I’m not offering a magic formula. I’m offering language on how to push back on false precision, and how to plan better: not answer “how long will this take?” but “what can we actually build with the time and the resources we have?”.