Your compare/contrast with building a bridge is a productive one. Designing software seems one of the toughest engineering problems, yet the science is so new (the most experienced are practically self trained), and there is so much we are still figuring out.

In the past we thought of software as I/O (inputs and outputs); essentially software engineering was considered “finding the best way to go from point A (input) to point B (output)” - i.e. the simple act of coding that Peter mentions.

Yet changing business requirements (shifting the I’s and O’s daily in respond to user requests, environmental changes) bring such systems to their knees; the underlying design is not robust enough to sustain those continual changes in an organized way.

For example I have a SQL programmer who makes 5 changes a week to our software and we have to go back-and-forth a half dozen times on every little tiny change he makes. The whole thing is just a growing rat’s nest of knarly scripting code with raw SQL statements embedded everywhere. Each change is taking progressively longer as his code becomes more complicated, and as things get worse, each change is more of a disaster that takes literally weeks and months to debug for production.

Enterprise business process software like SAP use gigantic frameworks to apply some method to the madness, but the method IS madness. These huge systems are not so useful to mid-size companies and agencies (say less than 200M revenue) which rapidly changing environments but cannot justify armies of consultants deploying huge systems which they will underutilize dramatically.

One issue here is that designers seem to forget that needs will change. Software systems delivery is an ongoing partnership. These days there are few packaged products that do anything nontrivial without the need for constant updating and modification.

The focus needs to be on building a system that can sustain a queue of changes without exponentially growing the complexity (i.e. complexity is ke^n where n is the number of features at any given time). Maybe some of this may be done through a component model, which to day is still fraught with problems. The thing is, automobile designers are getting it more or less right. Cars seem to break down less than computers, and the same ideas apply (cars these days are filled with embedded that work together in a network).

Very shades-of-The-Matrix …

It seems to me that people fail to realize that software is function and performance, not structure.

An application is not a bridge. It is a way, a method, a process, but old school managers treat them like buildings.

The key - it would seem - is to recognize the nature of the beast.

Software engineering is more like exploring than like laying brick and mortar. It is engineering, not construction. It is invention, not manufacture.

Most of all, it is creative, not rote.

That is to say, it is those things at its core.

The rest is coding. That part is essentially building a bridge. You can plan that part roughly the same way. Can you hit a snag in the coding? Of course … same as you can hit a snag driving piles for your bridge. Can there be defects in the final product? Of course - people make mistakes.

That’s only part of the answer, though.

Software “works” by display - by revelation - by illustration. If information comes out, software is working. If the right information comes out, the software is working properly. In that sense, sofware implementation is more like medicine - only medicine performed on something unintelligently (by comparison) designed.

Ah well - enough ramblings for a reply, eh.

Keep up the good work!