Is it Engineering or not?

I find it remarkable that we still can call the development of software, "software engineering" given how it's usually done in most organizations. What I've seen is that there's very little planning and what planning is made is focused on details that are miss the larger picture. To use an overused analogy: if we were building a bridge like we built software, we'd have very detailed plans for how to construct suspension cables but we're really building a cantilevered bridge. To top it off, instead of actually buying the cables, we're building them from scratch including mining the ore that supplies the metal!

Agile methods are even worse (in my opinion). Agile methods are touted as a great tool in the face of rapidly changing requirements. Probably, but they're rarely used that way. Instead they seem to supply a good excuse to management about why we don't need to do pesky documentations, requirements, etc. And worse, management actually seems to believe it. Agile methods are more like a couple of kids in the backyard who decide that they need a treehouse, so they start collecting scraps of wood and start nailing them to the tree in hopes that something vaguely treehouse-like will result.

If requirements are changing rapidly, perhaps the best engineering approach would be to NOT do anything until some of the larger fluctuations have died down. Requirements churn is usually a sign that the concept is either ill-conceived or less than half-baked. I understand the necessity of getting to market fast (although I have yet to understand why everybody's in such a rush) but getting there with crap is not the way to do it.

Some of the problem I think lies in how we educate people for careers in software development. We teach them all kinds of great theory (I love theory) and all kinds of great languages (Java, Ruby, what's next) and give them only 1 or 2 courses in how to actually conduct software development efforts. Certainly the ethics of how to responsibly develop software are rarely discussed.

Responsibility for change in this area lie with each individual developer, each development organization, each company hosting a development organization, and every consumer of software. Individual developers need to stop whining about how documentation is useless, testing doesn't make sense, and we just need to get it out the door. Organizations need to stop supporting sloppy development practice, shoddy products, and developers with the personalities of slugs. Consumers need to reconsider whether continuing to buy and thus support shoddy products is worth the money or whether it's better to just not use it and send a clear message to the developers. We did that in this country with domestic cars in the 70's and 80's when imports were clearly of better quality. When are we going to do it with software (not that imports are better in this case)???