> Your house example is how management wants to visualize software development, but it's just not an accurate analogy, and never will be. Software development is nothing like "real" engineering, despite what developers like to call themselves. When building a house or any real-world object, you can rely on physics to make time estimates. You know how long concrete takes to set; you know how long a machine takes to cut wood beams; you could even know how long it takes for a builder to lay bricks. You can then extrapolate this to the building requirements, and more-or-less give an informed estimate, where only unpredictable circumstances like weather or human-related issues could delay the project.

I fully disagree with that. Yes, you can absolutely rely on physics to be predictable in physical engineering, but I'd estimate there are similar consistencies in software engineering. You know how long things like the built time take and you can get averages on PR and design doc review times. There are going to be parts of a project that aren't full of unknowns that you can probably accurately predict (e.g. I have to change the color and text of a button or I need to spin up a new Redis instances and did that same thing on my last project). If you're building a house though, there are plenty of things you can't predict, same as with engineering. You can estimate how much concrete costs, but if you're supplier is in Canada and all of the sudden there's a 25% tariff slapped on the import your cost estimate could be fucked. Alternatively, what if the bricklayer breaks their arm a week before they're scheduled to start? In almost every project in almost every discipline there are unknown unknowns, but that doesn't stop them from providing estimates.

> Whereas software development depends entirely on humans (for now, at least; AI is not reliable yet), and there's no predictable physical component to it. Every project is entirely different from every other.

I mentioned it above, but I could not disagree with this more and if you really feel this way, I think you're not thinking things through. If I build an API endpoint to return all users from a database, I can probably pretty accurately predict how long it would take to build an endpoint to return a single user from that same database. If you did a project to build the front end of a sign in page, you can probably pretty accurately predict how long building the front end of a sign up page would take.

Even on projects where the project itself is fairly novel, not every part of the project will be and that can be a starting point. Even if you're building something entirely new, if you know you need to add a new database table, you might need to look at what their migration framework looks like, but you can probably get a fairly accurate estimate on the time it takes to do that part. Most software projects aren't 100% work that you've never done before and even estimating that work can be a good starting point and be helpful.

I also really disagree with the idea that just because it's physical means it's predictable. Concrete drys slower in cold weather, so unless you have a 100% accurate weather prediction there's unknowns there. You may estimate it's going to take 5 days to build the framing, but if a freak snowstorm happens and your crew now spends the first and last hour of the day shoveling snow and covering/uncovering everything on the build site, your estimate is out the window. Even ignoring that, it's not like building a house is a completely automated process. Even if you know exactly how long the concrete will take to dry there's a lot of people involved in the process of pouring it.