"It's no different for the software industry."
Yes it is, there are two types of project in the world - those where the time for production is a fairly well known and those where it's not. When you've built a few houses you know roughly how many bricks your bricklayers can lay in a day, you know how long it takes to install the plumbing, these are tasks that you do many times and within a certain degree of tolerance are highly predictable in terms of time required.
You can't do that with software, because everything you write is new (and if it isn't, you're doing it wrong, why aren't you taking advantage of reusable components?) so you simply cannot predict ahead of time how long something will take with any reasonable degree of guarantee. The same is true for many research projects, the same is true for a lot of engineering projects. Projects in industries like these aren't like production lines where you have masses of historical data on identical or near identical tasks to go on - you know your factory can churn out 10,000 chocolate bars in a day on average, but you don't know that your team of software developers can definitely solve problem x in a day.
As much as I disagree with how managers estimate time for projects, you can very well do that with software. However, you need software developers that are professionals, and not about being artistic. People that will stick to team guidelines, coding styles, design guidelines, etc, and people with experience. The more experience you have the better you'll get at estimating your own time.
And yes, I've seen that even with myself. In the early phase of a brand new project it can be harder to estimate time correctly, but as some of the technology in the project matured, other phases became a lot easier. Following design guidelines have reduced bugs to very low levels - near zero across over 400 KSLOC, most things users complain about are not bugs but product maturity (e.g. I don't have infrastructure in place to support what they want yet) - i.e. it's not bugs, but new features to add. (Bugs being defined as defects in existing code, not missing features.)
Software developers that insist that it cannot be done are simply (i) inexperienced, or (ii) do not know what they are doing and need to not be doing software.
"When requirements change, you change the contract through a renegotiation. If they don't want to change the contract, you don't change what you provide. That's standard practice for contracting."
This shows a complete lack of experience on your behalf on dealing with clients. If you act like this you'll a) often be wasting more of your time and their time renegotiating contracts than you will just doing the changes because the changes rarely come in one big bulk lump, but normally come in at a trickle, and b) Your customers wont be your customers because forcing them to waste time with a contract renegotiation over say, roughly a days work is the quickest way to piss them off and show how inflexible you are. They'll go elsewhere.
No. It shows you know you have contracts work. You are bound to the contract you've signed. If you don't follow the contract and they have a problem, then you are on the hook for what is written in the contract. If they ask you for something that is not in the contract, then you can do it - but it won't be something they'd be able to hold you to.
In the end, your customer may complain at first; but when they get what they want they'll be happy. Make the contract renegotiation easy for them, and show them that the renegotiation is as much about them getting what they want and keeping them happy as it is ensuring that you are properly paid.
Yes, there is a line where you can say - well, the contract doesn't say that, but we'll do it any way. And that's a line you have to figure out how to walk. But you also cannot simply roll over and say "well, if the customer says it do it" - you won't be in business long if you do.
And, FYI, the Defense Industry operates on this very principle. The US Government puts out an RFP; contractors respond with their proposals; one of them wins, and then immediately renegotiates the proposal before any work is actually done. They seem to be doing very well.
And ultimately, if they don't want to do it - then they're not worth having as a customer either as it will impose undue risk on you and your own business.
There's also the fact that it's impossible to write down a perfectly solid spec, if they want something different and you try to demand they pay for a change request or you demand contract renegotiation they're just as likely to find a hole in the spec (and there will be holes, writing a hole-proof spec is more difficult and time consuming than writing 100% bug-free software) and use that to make your life difficult.
And there's a difference between clarifying a point in the contract and product specification versus adding new features. As I said, there's a balance to be drawn. And businesses in every industry walk that line.
Software is no different except too many software developers enter into contracts without experience in contracting and then roll-over when their client wants a change.