[jacobian]

I'm curious: if you hired a contractor to, I dunno, paint your walls, would you accept "I don't know" as a time frame or price quote? If not, what's different about software development that makes "I don't know" a reasonable answer in our profession?

[Jtsummers]

Software development isn't (universally) a painting type task. In painting a room, the painter can estimate (by measuring) the amount of paint needed, they know from experience the time to acquire a particular color (if it needs to be mixed or can be bought readymade) in a particular volume, they know how long it takes to paint (they've done it many times before), how long to dry, and how many coats are needed for the type of surface.

Now, ask them to paint a mural instead. The estimates will change, they'll probably give you a broader range instead of being able to estimate almost down to the minute (and being off by no more than an hour or two) like someone just painting walls (with a known environment, surface type, and paint material).

Does the mural need to be designed? Are the desired qualities of the mural well-specified or will there be a series of back and forths? Maybe a set of prototypes (sketches) so that you can refine your requirements. At that point, the estimate for the total task (design and paint a mural, or design and develop a software application) becomes far less clear.

There are certainly programming tasks which are closer to the paint-a-wall task which are much easier to estimate reliably, but they're far from the only thing people in this field work on.

[kvmet]

This kind of thing destroys freelance devs who don't have context.

Customer: "Hi we need this small change." Dev: "No problem! Here's a quote for 4 hours"

Ignoring that 4 hours is probably less than the effort to consult, estimate, generate and process contracts, bill, do taxes... Then the customer comes back and asks for a revision which will at least require a Change-Order or a separate PO.

To some extent the overhead should be covered under labor burden but the reality is that in a sole proprietorship YOU are also the person doing the labor that is within the definition of "labor burden". It adds up extremely fast.

A million dollars would be a windfall if it landed in my checking account. On a development project with hardware and more than one dev it might as well be dust in the wind.

[xboxnolifes]

> what's different about software development that makes "I don't know" a reasonable answer in our profession?

The seemingly infinite amount of variations in software tasks and the ambiguity of the requirements? If my job involved only putting up or modifying API endpoints that involved querying a single SQL database, I'd get quite good at that and be able to tell you with very good accuracy how long an endpoint would take to put up.

Just as if I painted many walls before, I could reasonably tell you how long painting a wall would take based on the surface area, height, and amount of non-wall obstructions. Also, contractors tend to be their own salesmen, so just because they speak confidently, doesn't mean they are. It's not like contractors are universally famous for being on-time and underbudget.

[Cyphase]

If your job involved _only_ putting up or modifying API endpoints that involved querying a single SQL database, you could automate at least a good chunk of that. Maybe all of it.

How long would it take to build a system to automate API endpoints that query a single SQL database? It depends.

[beryilma]

Contractor horror stories are actually very common. They may not actually say to you "I don't know", but big delays in contractor jobs happen all the time. I would argue that software engineers are at least trying to be more honest about the unknowns of the work unlike some sleazy contractors.

[sanderjd]

My answer to this is that software engineering is a lot more like creating a blueprint than creating an artifact based on that blueprint. Or put another way, it's usually more of a design process than a manufacturing process. (I've switched analogies on you, but "painting walls" in your analogy is akin to "manufacturing artifacts" in mine.)

The "manufacturing the artifact" step in software is done automatically by the computer, when given the "blueprint" (code).

I guess to try to go back to your painting walls analogy. In my view, creating software is more like if someone asked you to create a wall-painting machine that will work for any room that fits a certain specification. They could contract you to paint just one room in this way, but that would certainly be harder than just painting the room! But more likely, they have a million rooms they want you to paint. Either way, the hard part is creating the room-painting machine. And it would indeed be quite difficult to give an accurate estimate of how long it will take to do that. But once that exists, you can easily estimate how long it will take to paint any individual room.

And real engineers, indeed, have this same issue with the design phase of projects, for the same reasons. Just like us, they try to break apart and estimate how long it will take to do that part, but just like us, my impression is that it is known to be fraught to accurately estimate that part of a project.

But also just like us, this is a continuum based on how novel the thing they are engineering is to them. On the one end of the spectrum, there is the equivalent of off-the-shelf software, like using a blueprint for a standard single-family home that's been built a million times already. And on the other end of the spectrum are things like designing the motor for the first model of a new electric vehicle manufacturer, where it's all brand new. But then there's a whole spectrum between those two, where it is fairly easy to break down and estimate the design process for things you've done a bunch of times, and nearly impossible for things you've never done.

This is a very long-winded way of saying that the difference comes down to how novel the project you're working on is! This is why freelance / contractor shops do best when they find a particular niche of a kind of thing to build, and then find clients who want them to build essentially the same thing over and over again. It really is possible to get very good at estimating this kind of nearly-cookie-cutter work. (I did this a bit for awhile back in the day, with multi-page Rails CRUD apps, and it was indeed easy to break things up and estimate.) But this is also why it can be frustrating to work with freelance / contract shops, because it behooves them to figure out how to fit your project into their cookie cutter, and that can end up being a worse outcome than building something bespoke, iteratively, without a detailed plan and estimate.