Classical Engineering Vs. Software Engineering

Unfortunately they are even more arcane than the code.

Look up the Vienna development method and predicate calculus if you want a real belly laugh.

It's the soft bit of software that makes it different from classical engineering. It's so mutable, best practice can vary dramatically, it's also very subjective and it tends to be managed reactively.

Another big difference is the materials side.
Any engineer will tell you that a rocket two feet long is almost certainly not going to make it in to orbit by itself, and that there's a reason there aren't too many one mile long wooden suspension bridges...

Unfortunately those sort of constraints are quite often unappreciated.

The biggest problem though in my opinion, is while the things we want to engineer change rapidly, the reason for it being engineerd changes, the people, the approach, sometimes the tools and the materials, it's rare you get to choose them, what's already used is the default, even if it's not the best choice.

Yet those who set those goals and resources and tools, refuse to accept that change is a given and that when you haven't prepared for it, it costs, more, a lot more, or you get less.

Engineer expectation, software, aside from bleeding edge, is 'easy' once you know the requirements.

From my view at a company that relies on both hardware and software engineering, the difference is not science and mathematics as much as software engineering does not practice the same level of discipline that hardware engineering does.

As compared to mechanical or even electrical engineering, software engineering is still in it's infancy, and on the steep slope section of the learning curve.

Add to that, the lack of quantifiable standards and physical restraints, and you can start to comprehend how far software engineering will need to evolve to reach the level of discipline you are looking for.

What is going on presently in software engineering is no different than the early days of the automobile, aviation, or electronics industries. People don't know what they don't know, and are still defining the best way to achieve the end result.

You can also argue that software is both more complex and harder to quantify than physical operations.

Software engineering at it's basis is no different than classical engineering. We just don't know enough to define the discipline and verify the performance.

Chas

Can we bring this one back from the dead?

In this discussion and the various blog posts, the conversation tends to hinge on the cargo cult argument: "If I do my work the way engineers do their work I must be an engineer". In the words of Dr. Pauli, that's not even wrong.

If you were a Software Engineer in the common sense of "Engineer":

You'd have a graduate degree in Software Engineering.

You'd have passed a certification exam demonstrating mastery of the knowledge and tools of your profession.

It's likely you would have spent some internship time working as an unlicensed software engineer under a practicing mentor.

You'd have a professional certification and/or license to practice as a Software Engineer from the institution recognized by your government as the institution permitted to grant such certification.

You'd have a code of conduct/ethics which you'd agreed to abide by. This would quite likely include some legal liability.

You'd be committed to ongoing professional development.

Otherwise you're a Programmer unnecessarily burdened with a sadly pretentious title.

"Programmer" is a fine title with a long and celebrated history.

It also has the advantage of getting bigger as the qualifiers get shorter. A "Java Programmer" can only do one thing. A "Programmer" can be expected to work, and have worked, competently in any language, given a short time to figure the ideosyncracies if it's a new language.

When I was running an R&D shop there were three software development titles: Programmer, Senior Programmer, and The Senior Programmer (who did not want to be called "Software Development Manager"). Seniors had both design and mentoring skills, "The Senior" did some coding but mainly architecture and process management.

When it came time to reward people for good work I gave them money, not meaningless titles.