Why software development is not same as building bridges

I came across a very old post on itmweb titled: Why is software development not viewed as R&D, but more like manufacturing? (http://www.itmweb.com/ubb/Forum3/HTML/000010.html).

One of the replies to the post argues that software development is similar to engineering projects like building bridges. That view couldn't be more off.

Equating software development with building bridges doesn't make much sense to me. For one, building bridges needs a lot of upfront design because you cant change the bridge once built. Software continuously undergoes changes. There is very little that can't be changed / rewritten in software. I would also agree with diltondalton - in that designers and builders of a product are the same. Another way of saying that is that in software, the worker on the ground will have to continuously create as opposed to the very mechanical nature of the their equivalent's work when building bridges. In fact, you don't want the workers building bridges to think. Thats the designer's job.

I would also agree with the spirit of the original post. If you are pedantic, you would argue that it differs from R&D in a manufacturing company. But it most definitely is not the same as manufacturing. As we try and bring in more and more lean manufacturing practices into software development, that becomes all the more clear.

Caution when choosing Lean Manufacturing practices

When we picked up Toyota's lean practices for use in software development, we underestimated the differences between manufacturing assembly line (hereafter "the line") and software development. I have made an effort to list some of these here and emphasize why we should be cautious while choosing lean manufacturing practices into software development.
1. The line doesn't have any slack. You can't play AoE when the line is moving with units that need you to perform a task. By contrast, software development is asynchronous.
2. Work performed at different stages of the line are very small and always take the same effort - because work is done on a line that is moving. By contrast, work performed at different stages of software development runs into hours / days and varies based on the nature of the story in question
3. Stories though independent, are part of the whole (system). They can't exist independently nor be sold independent of the overall software system, unlike units manufactured on the line.
4. Chaman pointed out that software development is iterative in contrast to manufacturing.
5. The equivalent of software development in manufacturing is probably Product Research & Development (R&D) rather than the line itself.

I am sure there are many more differences. That said, we could as easily build a list of similarities. They key point is to be cognizant of the differences, and ensure we are cautious when choosing and implementing lean manufacturing practices in the software development context.