General discussion


Classical Engineering Vs. Software Engineering

By umzyift ·
Seeing that Classical Engineering strongly relies on theories of mathematics and rules of God (Physics) hence it is always referred to as 'good practise' . How far is Software Engineering from using same 'best practice' of Mathematics ?Is there a mathematics of Software Engeneering that can play a role similar to the mathematics of other engineering disciplines?
To what I understand, Software Engineering can never reach the level of Classical Engineering as in usage of 'Best Practise' because of several reasons,
-ever changing technology
-different view of same problem
-different solution for same problem
-not best practise available
-lack of standards

This conversation is currently closed to new comments.

8 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Comments

Collapse -

Biggest problem - lack of standards

by j-mart In reply to Classical Engineering Vs. ...

Standards make classical engineering a breeze. you can build a machine out of parts sourced from all over the world out of that comply to well defined standards. Manufacturing your equipment to meet various tried and true codes / standards gives your customer confidence that your product will perform to their expectations.

Collapse -

That is somewhat misleading.

by Tony Hopkinson In reply to Biggest problem - lack of ...

In classical enginneering as you define your requirement you increase the number of constraints to the point where there are very few practical solutions. At a certain point, you cannot have a radical change of approach, without knowing that all you have done up to press has been wasted.

The mutability of software gives you the opportunity and the pain of doing those.

There are many standards, becasue there are many right solutions and each one has it's own.

A classical engineering approach to software enginneering gives you none of those opportunities and those are why it's so valuable.

Collapse -

The lack of hardware and interface standards

by j-mart In reply to That is somewhat misleadi ...

Often caused by the policy of a well known OS that has standards that vary with each reincarnation. This causes much "reinventing of the wheel" by the software vendors to keep their products from breaking with each new windows release. If every time a manufacturer made a production run of a product, they changed the thread form of the nuts and bolts just to force a level of redundancy into a peice of equipment, would be an unaceptable practice, in the software game this seems to be common practice

Collapse -

I agree to an extent

by Tony Hopkinson In reply to The lack of hardware and ...

But mutability introduces a whole new qualitative level. The more it get's locked down the less soft it is. A straight jacket is as much of an encumbrance, as a multiplicity of badly defined options.

Collapse -

There are mathemtical descriptions of software

by Tony Hopkinson In reply to Classical Engineering Vs. ...

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.

Collapse -

Lack of Discipline

by TheChas In reply to Classical Engineering Vs. ...

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.


Collapse -


by santeewelding In reply to Classical Engineering Vs. ...

This is turning out to be good. Rapt-like good.

Collapse -

It's not about how you work

by Marc Thibault In reply to Classical Engineering Vs. ...

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&amp 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.

Back to Software Forum
8 total posts (Page 1 of 1)  

Related Discussions

Related Forums