OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: XML As Fall Guy

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS