NASA JPL can't estimate the cost of software accurately - how can you?
ceh.nasa.gov
ceh.nasa.gov
I work as a government contractor doing engineering for the FAA. Most of my senior peers, and our bosses are of the baby boomer generation. (Strangely, the middle generation is entirely unrepresented here and we have only baby boomers or a few milennials, no one in between.) They have a good handle on how digital logic gates and analog circuits work, but they don't quite seem to know the right way to think about software. (Example, true story: My boss came in the other day and asked how much variation there is in flashing rate of some lights we're controlling. The programmer of the control unit was perplexed and said, "The flashing is done entirely by software, so... there's no variation." My boss said, "OK but what I mean is, how does the flashing rate vary with temperature?" That's what I mean by them not really having a handle on how software differs from circuits.)
So, combine these two things: physical things being replaced with information, and a generation of managers who don't really "get" software. Now, you take these things that would have been aspects of the schedule as separate hardware pieces to be developed or other physical things, and chuck more and more of them over the fence into this nebulous category of "the software" and (in the minds of the schedule-making people) it's kind of like a black hole: stuff disappears into and the radius doesn't increase, but it's also a massive heavy thing that's hard to think about.
So my argument is that not all of the difficulty with estimating the cost of software is the "fault" of the programmers or the nature of software. You have to look at the fact that software is doing more but nonprogrammers don't know how to think about software and so throw it all into this sort of schedule black hole.