[Jcampuzano2]

Engineer as a term has already drifted vastly since nobody in the field of "Software Engineering" is actually an Engineer if we go by a strict definitions.

Engineers are accredited and in some countries even come with a title.

[keeda]

> ... nobody in the field of "Software Engineering" is actually an Engineer if we go by a strict definitions.

This is a pet peeve of mine, so while I understand what you mean, I will challenge you to come up with a strict definition that excludes software engineering!

And since I've had this discussion before, I'll pre-emptively hazard a guess that the argument boils down to "rigor", and point out that a) economic feasibility is a key part of engineering, b) the level of rigor applied to any project is a function of economics, and c) the economics of software projects is a very wide range.

Put another way, statistically most devs work on projects where the blast radius of failure is some minor inconvenience to like, 5 users. We really don't need rigor there, so I can see where you're coming from. But on the other extreme like aviation software, an appropriately extreme level of rigor is applied.

[coldtea]

>I will challenge you to come up with a strict definition that excludes software engineering!

"Structured, mature, legally enforced, physically grounded standards based approach to the construction of repeatable, reliable, verifiable, artifacts under stable (to the degree that matters) external constraints".

Some niche software development (e.g. NASA/JPL coding projects with special rules, practices, MISRA etc) can look like that.

99.9% of the time though, software "engineering" is an ad hoc, mix and match, semi-random, always changing requirements and environments, half-art half-guess, process, by unlicensed practicioners, that is only regulated at some minor aspects of its operation (like GDPR, or accessibility requirements), if that.

[fc417fc802]

By that definition the vast majority of historic engineers weren't "real" engineers. It's correct to claim that software engineering isn't currently an accredited profession and it's also quite reasonable to question the extent to which the vast majority of software development qualifies as the practice of engineering. But the latter is highly subjective and will likely also rule out a significant fraction of the grunt work that accredited engineers perform.

Which is to say, engineer the job title is distinct from engineering the activity is distinct from engineer the accreditation.

[coldtea]

>By that definition the vast majority of historic engineers weren't "real" engineers.

And they weren't. They were craftsmen and tradesmen, e.g. stonemasons.

[rcxdude]

This basically makes civil/structural engineers the only real engineers. Maybe people working on medical devices or military kit. 'Stable external constraints' still disqualifies most of those, though. Every single kind of engineering has to deal with the spec changing.

Also, software engineering is ahead of a few other disciplines of engineering on rigor in some dimensions. I feel like most software engineers don't understand how good software tools are at change management compared to pretty much anything else. (and that having good change management is a baseline, as opposed to a decent chance of not having any at all).

[da_chicken]

The only word doing any work at all in that definition is "artifacts", and the problem is that the methodology that is actually foundational to engineering need not be applied to physical objects. Further, it's not clear that this methodology shouldn't be rigorously applied to non-"artifacts" which that can cause equal or greater harms when created negligently.

The definition I always saw used was this one, I think:

> Engineering is the profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is applied with judgment to develop ways to utilize, economically, the materials and forces of nature for the benefit of mankind.

This sounds like it should exclude software design and development. Except it doesn't need to, and it's not really useful to exclude it simply because the definition isn't broad enough. The definition isn't engineering. The definition is trying to describe and encapsulate the reality of engineering. Nuclear and modern electrical engineers frequently never create anything physical in their careers whatsoever. Nuclear engineers manage power generation at facilities that others designed and built, while electrical engineers are frequently just dealing with signal processing. They are not less rigorous in their methodology.

The reality is that engineering is the methodical application of constraints to solve a problem. And it is the methodology that is the valuable aspect. The knowledge is necessary for each discipline, but it is itself fundamentally a prerequisite. There is a reason engineering is a single school of many disciplines.

Meanwhile, the reason that software engineering looks like half-art and half-guess has a lot more to do with software as a non-theoretical field of study only being about 60 years old in practical terms. The fundamental works of the field like The Art of Computer Programming haven't even been written yet.

Whatever happens to software development and operational systems administration in the next 50 years, however, both roles almost certainly would benefit society by becoming actual professions. Their responsibility to society as a whole has been allowed to be understated, and we're well past the days when a computer bug causing the kinds of deaths and damages such as we'd see from a civic work failure or automotive design flaw sounds unreasonable. Indeed, that actually sound fortunate given some of the software catastrophes that have occurred.

[coldtea]

>The only word doing any work at all in that definition is "artifacts"

That's the subject, the only word that is NOT doing any work there (since both regular and software engineering produce artifacts).

Words that do the heavy work in that phrase are:

structured, mature, legally enforced, standards-based approach - for repeatable, reliable, verifiable, - artifacts - under stable external constraints

Software can sometime appear to touch those.

E.g. there are "standards", like HTML or like ARIA, so it's "standards-based" too! But those standards are loosely enforced, usually not mandated, loosely defined, and ad-hoc implemented with all kinds of diverting.

Or e.g. software can some times be repeatable. E.g. reproducible builds (to touch upon one aspect). But that's again left to the implementor, seldom followed (almost never for most software work, only in niche industries).

In general, software is not engineering (in the strict sense) because it's anything goes, all the above conditions can or cannot be handled (in any random set), the final work is a moving target, and verification is fuzzy, if it even happens.

>The reality is that engineering is the methodical application of constraints to solve a problem.

In that case, following specific constraits to solve a math problem, or to draw an artwork (e.g. using perspective) is also "engineering". That's too loose a term to be of any use.

Even accepting that, the degree of "methological" in software "engineering" versus e.g. civic or aviation engineering is orders of magnitude less.

[da_chicken]

> In that case, following specific constraits to solve a math problem, or to draw an artwork (e.g. using perspective) is also "engineering". That's too loose a term to be of any use.

You're being deliberately obtuse and consistently choosing semantic equivocation, so I'm not really going to engage with you any further, but the point is that there is a specific methodology that is unique to engineering. You've heard of the Scientific Method. There is also the Engineering Method.

Ultimately, though, the problem is you're arguing that the map is the territory. The the arbitrary linguistics we have chosen in the past must always and forever be the same. And that's just not a useful model of reality.

[keeda]

>* ... legally enforced ...*

Other than that part (most countries in the world do not have regulations or licensing requirements for most engineering disciplines) I would agree. But I would also point out the set of software projects that meet that definition is much larger than those you listed.

As mentioned, it's a matter of economics, so the rigor scales with the pain it can cause if something that goes wrong. Hence any software that has a high blast radius is that rigorously built, probably even more. There are entire categories (not just individual examples!) of such projects. An obvious category are platforms that run or build other applications: OS kernels, databases, compilers, frameworks, cloud platforms (yes those 9's are an industry standard), and so on.

Then there are those regulated ones like automotive, aviation and medical software. There is even a case to be made for critical financial software.

Another less obvious category applies to any large software services company that has oncall engineers, because the high cost of engineers quickly climbs and quality processes quickly get installed, which basically amount to those critera you listed.

That internal LoB app with 5 users? That level of rigor simply does not make economic sense. Which is probably what you mean by:

> 99.9% of the time though, software "engineering" is an ad hoc, mix and match, semi-random, always changing requirements and environments, half-art half-guess, process, by unlicensed practicioners, that is only regulated at some minor aspects of its operation (like GDPR, or accessibility requirements), if that.

To that I'll say, as someone whose first site outage as an intern was an actual industrial manufacturing factory (not an AbstractFactoryFactory!) a surprisingly large fraction of projects in other engineering disciplines match that description ;-)

[coldtea]

>most countries in the world do not have regulations or licensing requirements for most engineering disciplines

Well, then in those countries those disciplines aren't treated as enginering.

Any country worth its name and with a rule of law, would have regulations and licensing requirements for electricians, civic engineers, structural engineers, aviation engineers, chemical engineers, etc.

I mean, they had building rules at the time of Babylon:

https://talk.build/construct-iq/ancient-babylon-and-the-firs...

And even in medieval times, working in certain fields that we'd call engineering today, was legally restricted to specific guilds.

[keeda]

If you look at the number of countries that require licensing to practice, there are literally a handful. It doesn't make sense to dismiss the vast, vast majority of engineers in the world as "not really engineers."

[arealaccount]

Yea we do standups every day and plan story points twice a month???

[Jcampuzano2]

I don't really disagree with you. I was just pointing out how the parent mentioned how "engineering" is changing when it already has changed many many times.

Of course I want the best of the best who are top notch and rigorously trained working on mission critical software.

[2OEH8eoCRo0]

It's a pet peeve because the truth hurts. We (most of us) aren't doing anything that resembles engineering.

[keeda]

I'd agree that applies to people, or more accurately specific projects, but not the discipline of software engineering as a whole.

Even most of the projects I personally have worked on simply did not need "engineering" as such, but other projects where uptime was critical and the cost of failure was high, there was a much higher level of rigor.

[skywhopper]

“Accredited”

[keeda]

Most countries do not need accreditation for engineers.

[analog31]

Engineers are accredited in the US too. But there is an "industrial exemption" that allows you to work as an engineer without a license for certain kinds of employers. You just can't offer engineering services to the public without a license. This is more important in some fields than in others.

Where I work, there are plenty of non licensed engineers, but we pay a 3rd party agency for regulatory approval. The people who work for that agency are licensed engineers. Their expertise is knowing the regulations backwards and forwards.

Here's what I think is happening within industry. More and more work done by people with engineering job titles consists of organizing and arranging things, fitting things together, troubleshooting, dealing with vendors, etc. The reason is the complexity of products. As the number of "things" in a product increases by O(n), the number of relationships increases by O(n^2), so the majority of work has to do with relationships. A small fraction of engineers engages in traditional quantitative engineering. In my observation, the average age of those people is around 60, with a few in their 70s.

[gombosg]

I started my career as a machine designer (mechanical engineering), designing some machines for FMCG factories.

It wasn't that much different from SWE - mostly looking up catalogs, connecting certain pre-made pieces together with custom parts and lots of testing of the final plan to make sure there are no collisions and every movement is constrained properly.

95% of the time no load or sizing calculations were necessary - we just oversized everything based on tacit knowledge (the greybeards reviewing the plans) since these machines were not mass produced and choosing somewhat bigger parts was not expensive given that these machines would operate and produce value 24/7 for years.

(I hope the analogy to software engineering is visible!)

What I'm saying is that the level of "engineering rigor" heavily depends on the field where engineers are operating within. Even certain SWE fields (healthcare, finance, aviation etc.) have more regulation and require more rigor than others.

[lkmill]

as an actual engineer i just feel sad. i should probably feel happy but i like solving problems. fml i have becomea luddite.

[therealdrag0]

I get it. But there’s plenty of engineering to do in any serious system. I am in a very AI forward company using AI for everything, but I still am solving engineering problems every day.

[umanwizard]

The concept of engineer predates the accreditation systems you’re referring to by centuries.

[jjtheblunt]

i think you accidentally overlooked accredited engineers who happen to be writing software

[Jcampuzano2]

Of course there are engineers who write software, I'm just speaking about the majority of roles where thats not the case.