[lug] Developer abuse

Michael D. Hirsch mhirsch at nubridges.com
Tue Nov 16 14:43:53 MST 2004

On Tuesday 16 November 2004 03:36 pm, Jeffrey Siegal wrote:
> John Mueller wrote:
> > Now there is a big difference between the construction industry and the
> > software development industry in that construction deals with the
> > physical aspects of the world primarily (so there are physical
> > limitations) and the software development industry deals with the virtual
> > (which has less limitations than the physical world)......
> That's basically it, as others have alluded.  Once you figure out how to
> build a building, that doesn't mean you don't want to build any more
> buildings.  You still need to undertake the substnatial task of moving
> the atoms around, even in the case of cookie-cutter constriction where
> every building is exactly the same.
> In software, people rarely if ever constrict exactly the same system
> over and over again, and don't even generally construct systems that are
> very similar (since it makes more sense to just reuse the previous one).
> So the nature of building construction and software construction are
> just totally different in practice.

I agree.  software has the unusual property that once you've built it once, 
you can duplicate it for free.   At worst, you can supply a build scipt  to 
reproduce it.  It is all product development and the manufacturing is free.

I think construction is a really poor model for software development.  In most 
software development, you are trying to do something you've never done 
before.  Sometimes it is similar to a previous project, but then you are 
trying to do it a different way.  If it were the same, you would just repeat 
the previous steps and you could do it without needing lots of planning 

Software development is better modeled as new product development.  Even the 
best manufacturing companies understand that the process of designing a new 
product is completely different from the manufacturing process and needs to 
be treated differently.  You have uncertain requirements, a different set of 
tools, possibly a new team, and unsolved problems that need to be overcome.  
Saying in advance how long it will take to solve an unzolved problem is very 


More information about the LUG mailing list