

NASA JPL can't estimate the cost of software accurately - how can you? - warren_s
http://www.ceh.nasa.gov/downloadfiles/Web%20Links/cost_hb_public-6-5.pdf

======
phaedrus
Buckminster Fuller predicted a future in which physical structures are
increasingly replaced by _information_ (with the implication that the
information accomplishes the same task as the physical structure, but better).

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.

