I guess I see it both ways. Things can definitely be improved, but we can never reach the quality levels of other engineering or scientific fields. It is good that tools such as UML and design patterns are finally reaching critical mass, but we've seen enough silver bullets to know that new tools aren't the answer. There needs to be real changes in the software development life cycle, on both sides of the fence (business and technical).
In most engineering fields, the cost of the engineering is a small fraction of total project cost. Not so in Software Engineering, where the marginal cost to replicate copies is zero. One could argue that software designs are to programmers as blueprints are to construction workers, but that would be a damn expensive design. It is intuitively obvious that modification of a bridge design after construction has begun is going to be very expensive. Some business folks (and some developers) do not understand the cost of scope creep in software, both in terms of rework and loss of design integrity.
In most science fields, the most important skill is probably the ability to make verifiable predictions. Developers who really understood Computer Science would never blame "data corruption" during integration testing like they were accusing an unslayable mythical beast -- they would look for the root cause. If they seriously applied the scientific method in their work, they would take notes -- they would comment their code and SCM checkins, they could determine which changes were installed to QA before some bug appeared.
Slashdot Mirror
I guess I see it both ways. Things can definitely be improved, but we can never reach the quality levels of other engineering or scientific fields. It is good that tools such as UML and design patterns are finally reaching critical mass, but we've seen enough silver bullets to know that new tools aren't the answer. There needs to be real changes in the software development life cycle, on both sides of the fence (business and technical). In most engineering fields, the cost of the engineering is a small fraction of total project cost. Not so in Software Engineering, where the marginal cost to replicate copies is zero. One could argue that software designs are to programmers as blueprints are to construction workers, but that would be a damn expensive design. It is intuitively obvious that modification of a bridge design after construction has begun is going to be very expensive. Some business folks (and some developers) do not understand the cost of scope creep in software, both in terms of rework and loss of design integrity. In most science fields, the most important skill is probably the ability to make verifiable predictions. Developers who really understood Computer Science would never blame "data corruption" during integration testing like they were accusing an unslayable mythical beast -- they would look for the root cause. If they seriously applied the scientific method in their work, they would take notes -- they would comment their code and SCM checkins, they could determine which changes were installed to QA before some bug appeared.