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.
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)
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.
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.
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.
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.
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)
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.
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.
Is this wishful thinking or actual experience? :-)
Sounds a lot like what it should be vs what it actually is.
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.