To me the term didn't come from HR it came from trying to get "programmers" to think in terms of constraints, value, risks etc. Seems a pretty clear and simple definition.
The reason I think its not taken off in the same ways as say mechanical engineering is because in general customers cannot actually see the product, only certain elements of its outputs.
If you couldn't see bridges either in use or after a failure. You just saw cars disappear at one end and appear at the other, not even able to measure the gap or time taken to cross in any meaningful way then structural engineers would bullshit and self grandise as much as software engineers.
Maybe one day the average person will know enough to hold us to account, then we will begin engineering properly.
The trend of giving high sounding titles started decades ago as more and more educated people entered the workforce and involves all jobs.
Manager? Vice president.
Secretary? Executive assistant.
Developer? Engineer.
Reports and collects some data for his bosses? Data analyst.
Warehouse worker? Logistics and distribution specialist.
It doesn't have to always be self-aggrandizing for it to be true that lots of people are now called VP who used to just be middle-managers.
If not, then, at least in my mind, it seems difficult to pin down exactly how software engineering can occupy a space in the domain of modern engineering.
Some sort of specific liability in the legal code could make sense, though.
As opposed to learn about a type of algorithms, some math, some language or some pattern.
10 years latter, I’m glad for the exposure.
It was more useful to understand and talk to folks on the sides of the dev department : security, ops, qa, support. Heck, even product.
I felt that with those, the dev could monkey patch whatever together and still be part of some engineering process.
Now I don’t know. I sure do push code around.
In physical engineering, you really get one chance. If you make a mistake or miscalculation, there is a cost associated with undoing what's been done, as well as trying again.
In software, there is no such additional cost. You can trivially start from scratch, or any point between scratch and here, at any given time. There is no disposal cost.
Security breaches, locked in data (poor dB structure or no direct access) reverse engineering undocumented functionality, even just dismantling supporting infrastructure and migration costs are huge. Another huge factor is when business logic is codified and the knowledge is lost from the business and only temprarily held by transient consultants or developers.
An sap project for a single region for a $1bn per year company can easy cost over $10m and no software is being developed, only config, process change and data migration. Never mind increased staff turnover reduced productivity.
But very few people have the experience and expertise to understand what they are really signing up for.
Just think about a 3d model can do for a construction project and what that would look like for code and you can see how poorly we do this really.
(Make software actually be engineered)
That's without even considering all the kinds of rules-lawyering that would be applied afterwards.
Yeah, we call them civil engineers.
In the US, in order to be an engineer one either had to have a license to call themselves an engineer, or a company could confer that title to employees. These days, it's less about the specific education, and instead the process of solving problems.
Engineering is a discipline which may be applied to many domains, including software. I define an engineer as someone who uses fundamental principles and processes of science and engineering to solve real world problems.
Our customers need to ask a skilled expert a question and receive an answer.
If I merely implemented code to achieve this goal, I would not consider that engineering, but rather coding.
Instead, if I first defined the problem statement, gathered requirements, documented assumptions, broke down the problem into discrete deliverables, defined metrics and success criteria, and created a plan of record, that would be engineering.
I have a formal education in engineering, and aside from the mathematical and science fundamentals required for engineering, a large portion of my education was dedicated to the process of solving problems (also proudly, a good portion was dedicated to learning about ethics as well).
Engineering involves risk tradeoffs, and if your developers are not making your risk decisions then they are not engineers -- and also you're going to spend a lot more money producing software (the authority to do risk assessment should always be as close to the "in the trenches" work as possible, every degree of removal invites the risk decisions to be made on lower-quality more-aggregated more-gutfeel information rather than clear metrics).
Most of computer programming is instead tinkering -- build a proof of concept, put it under stress, see what is being stressed, buttress those parts. The fundamental idea of architecture, "let's add some structure in advance so that we can build a self-sustaining system and take away the scaffolding later," is only really seen today maybe in test suites or so? Those are the scaffolds of our day I think. We're still in very early years for computing as a proper engineering discipline. But at least we do make some simple risk calculations.
Most of mechanical engineering is still tinkering. Not all problems are solved. Many of the people here pining for "real engineering in software" need more interdisciplinary experience, ffs.
I can only speak from my undergrad experience, but almost every engineering discipline took the same background courses, as well as mechanical, thermal, fluid, and electrical engineering classes and from there, went on to take courses related directly to their field.
From my experience, tinkering is another way to say prototyping or building a proof of concept.
As we've gained experience, the need to prototype the same solutions decreases, but when learning new tools and methodologies, experimenting and prototyping is very much part of the engineering process.
We do not. Civil engineer is a specific thing, with training, education, and licensing. The person who designed the system being installed or serviced was likely a civil engineer, the plumber is a plumber. And that's ok, everyone doesn't have to be an engineer. Being an engineer isn't inherently better than being a non-engineer.
> an engineer as someone who uses fundamental principles and processes of science and engineering
Do you see how saying an engineer is someone who does engineering isn't useful to other people? I'm sure you know what you mean, but basically everyone is and is not an engineer according to your definition.
Or a plumber can just be a guy following a plan and cutting and gluing pipes together.
Yes. That is the joke (among non-civil engineers with civil engineer friends).
> Do you see how saying an engineer is someone who does engineering isn't useful to other people?
No. Because that is not what I wrote.
I also provided a concrete problem, along with an engineering and non-engineering approach to solving it.
This is the first I've seen this point in the discussion. Engineering is considered a profession, distinct from a vocation. The term derives from professing an oath to serve the public in an ethical manner. If developers had to take a similar oath, I wonder if it would open them up to civil/criminal liability when they acted unethically (e.g., creating code in a social media application with the goal of manipulating behavior for profit)
With software, true engineering only happens if the development model can follow such a process. Nobody wants to put in the work to do this for all code though.
Being a good engineer is adopting the right combination of methodologies to fit the problem space.
Being a good software engineer means knowing what you should plan out in advance and what you need to test and design as you go.
I'm not convinced there is much utility in conferring the attribute of engineer to someone who is not practicing engineering when it's just as possible to say "She studied engineering" or "She majored in engineering" to denote the status of having an engineering degree but not engaging in the doing of engineering.
I don't think this is actually useful without strict definitions of what constitutes engineering. If I go to a homeopath who prescribes an herbal tea to cure my cancer are they "practicing medicine"? The law says they are not, and cannot, because of clear definitions of the term.
More seriously, the first programmers were electric/electronic engineers, so the engineer title was probably inherited. And game engines actually require lots of math and physics.
>Economists don't call themselves engineers and engineers don't call themselves economists.
There are quite a few universities that offer courses/degrees in "financial engineering" and they often are in the mathematics/economics colleges and don't have a typical engineering curriculum as you laid out.
I think shat this article fails to note is this engineer light/technician class which tends to be the more hands on portion of "engineering" in the case of sw, they would be more light engineering more programmer less overall design. AKA your systems architect/principal enginner is probably doing "engineering" the software engineers are likely just programmers.
Some would define it differently as someone who has an engineering license. There are States who have actually presented lawsuits aimed at preventing people from describing themselves "engineer" if they don't have that license. And, while an engineering degree is the more common first step in the licensing procedure, it's possible for one to get a license without an engineering degree. In the legal sense, they are more of an engineer than someone with a degree and no license.
Regarding the plumber, I think the mechanical engineer who designs the plumbing system would be the engineer, while the plumber is the technician. Just like the electrical engineer designs the system but an electrician installs it. Both roles are equally important but shouldn't be conflated.
(FWIW, I don't subscribe to that notion of what "engineering" is)
You can have the exact same curriculum and be called engineer or not be called engineer, depending on the university. You can even learn nothing related to engineering and have an engineer title, or the other way round.
I'm not saying you're wrong (especially the first part), but there's a lot more to it, especially in countries where 'engineer' is a protected name/profession.
Personal opinion: I don't care. My degree is "Computer Science", not "Computer or Software Engineering" and I see myself as a Software Developer (although I will allow programmer)
Every degree in my school's college of engineering was BS/MS. And I think something like 25 of 27 were "degrees in engineering".
If you want to go full circle, they are "degrees in engineering" because they're accredited by ABET, and satisfy the first requirement towards licensure and a PE.
There is no simple definition, which is the whole point of accreditation and licensing boards.
ETA: But if the programs in your hypothetical have an identical curriculum (and both are accredited), then yes, they would equally be "degrees in engineering".
If you design pacemaker software, you're an engineer. If you build RESTful websites, you're not. I say that as someone who builds RESTful websites.
The reason engineers need difficult certification exams is, so they don't destroy lives or expensive property.
There was a programming PE (USA) at some point, but it was closed.