On 12/3/2013 6:53 PM, Stephen Cameron wrote:
> All this discussion of logistics and quality control, engines, brakes
> etc. misses the point that I've tried to make that *software is
> different*, drawing analogies is actually dangerous (but something done
> all the time in our minds). I believe that you cannot separate the
> design from the production of software in any meaningful way.
This isn't settled for me. Sometimes I think that, sometimes I don't.
Right now I'm thinking back to a time when I worked at designing
hardware - radiation detectors. Our sales people had gotten a job to
build a replacement for another company's unusual design, and only four
units at that. It was very difficult to design, especially since the
original used certain items that would have been hard to impossible for
us to get. Also, the unit was very long and needed unusual internal
support structures.
I designed it and we were about to start cutting metal, when after a
review I realized that it wouldn't work - it could not be assembled. We
took a month and completely redesigned the internals.
Because of the difficulty and novelty of the design, when I had
estimated the cost to build, I assumed that we would have to do one
complete rework, and that a rework would cost almost as much as building
another. I moved on to another job before this contract was completed,
but I later found out that in fact the first unit had to be completely
rebuilt. The manufacturing cost came in very close to what I had estimated.
So how was that different from what we've been saying for software?
Except of course for the complexity, but I mean in terms of the
estimation, flow, and iteration of the program.
This example illustrates why I'm not so sure that software development
is really fundamentally different from hardware development. I'm
inclined to think that the most significant things that make software
hard to develop (and manage the development of) are 1) the complexity,
and 2) the fact that a lot more creativity is needed than managers want
to credit.
The matter of scale is another matter. I see many people getting mixed
up about small vs large scale. Large scale for any kind of project is
difficult to manage. Small scale, much of the information can be held
in the heads of one or a few people. Iterations are quick and easy.
Communication is easy, or at least easier. It's feasible for one or all
participants to understand the problem domain and to grasp what the
system has to do. For large systems, it's quite otherwise.
If you don't know how to manage and develop a small software project,
then surely you're not going to be able to manage a large software
project well! The reverse isn't the case, though, sad to say.
