
Universal Engineering Principles - timkofu
What principles are common to all Engineering disciplines? What makes Engineering &quot;Engineering&quot;?
======
CyberFonic
I tend to look at engineering as encompassing a series of building blocks:

* understand the physics of your discipline at the application scale. By scale I mean that the physics we need to understand are very different for structural engineering to build a steel bridge to the semiconductor atom level design to build a CPU chip. But it is physics in both those examples.

* have a proven model (usually mathematical and/or implemented on a computers) that allows you to understand, analyse and predict the realm of potential designs.

* understand the requirements to a comprehensive level of detail.

* evolve a design, using the models, that will fulfil the above requirements.

* verify through simulation, further analysis, etc that the design is "correct".

* using the blueprints developed in the previous steps, construct the solution.

* operate the solution and verify the accuracy of the model(s). In many fields of engineering, this allows the models to be fine-tuned based on experience.

It is interesting to note that early steel bridges were typically over-
engineered compared to those designed today. With experience and more refined
modelling the margins for error have been reduced. Sometimes with dire
consequences.

Of course, in well established areas of engineering, there are numerous
standards and empirical knowledge that makes the design process less demanding
than for emergent areas.

------
airbreather
One of my engineering lecturers said something like, "You will find many
people through your travels who can design and build the sort of things things
that you will in your career, but it is the engineer who can do them safely,
to a known quality, budget and schedule". (Usually)

~~~
atmosx
Was he an academic? I still have to meet an engineer who will deliver on
budget and schedule consistently. Quality in software engineering is a grey
area.

~~~
airbreather
Because you are dealing with people who are not trained as engineers, practice
little of the engineering patterns, yet insist on calling themselves
"engineers" because they think it makes them sound cool.

An engineer that builds software to a known quality and time will generally
use a V-model (all requirements are defined, then validated) and won't spend
most mornings standing around talking about new ideas their breakfast acid
gave them to try out in the next 24 hours. The engineer will also generally
not commence "construction" until "design" is near or substantially complete,
or else budget/schedule/quality are unable to be predicted, even by god.

It all leads back to the eternal question in software, "how will I know when I
am finished?" (the software). "When you have done what you said you will you
do". At which point it often breaks down because "make something cool" isn't
usually a measurable objective that satisfies a requirement, unless you work
for Hasbro, maybe.

Engineered software is built and tested to satisfy specific requirements that
solve a problem (to meet a need). It is often perceived as expensive and slow,
but is the process to follow for a chance of known and measureable results.

That is engineering - designing, then building, then testing and validating
that the requirements are being met, satisfying a need.

TDD starts to get you near there, if all the tests are written first, or at
least to some sort of hierarchy of detail concurrently.

Starting something you don't know how it's going to end is speculative
exploration, and there is nothing wrong with that, but it is not engineering
and in engineering projects is usually limited to very small "proof of
concept" phase up front before most aspects of design are fixed and detailed
engineering commences.

Quality in software is not as nearly gray as many like to think, it is just
the cost to not operate in a way where 90% of the outcomes fall in the gray
area is perceived as too expensive/slow.

And also because if you are not engineering a bridge and you can make "pivots"
17/18ths of the way through, but just at way greater risk/desperation than any
sane engineer would do unless at war or halfway back from the moon and out of
oxygen.

Finally, the engineer will follow practices and procedures that they are able
to, and prepared to, defend in court if someone dies as an associated result
and the grieving widow wants revenge.

~~~
atmosx
Is this wishful thinking or actual experience? :-)

Sounds a lot like what it should be vs what it actually is.

------
atmosx
To me engineer is anyone that counts before the implementation. Even if it is
back of the envelope calculations.

Two developers came requesting a Kafka partition topic scale-up. One of them
knew how many jobs per second his workers consume, how many messages per
second were going thorough the cluster, etc. The other did not. One acts as an
engineer the one does not.

You wanna be an engineer? Easy, learn how to count. And to give a pass to
those who don’t, counting is not easy. Most likely you will get it wrong, you
might be counting the wrong metrics, etc. But counting makes all the
difference in the world.

