Re: [xml-dev] RE: XML As Fall Guy

[Thomas Passin <list1@tompassin.net>]

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.