Why do "programmers" call themselves... "engineers"?!

[SiliconWizard]

This is a very common question that has been asked for several decades now. Is software development engineering? If not, what can we change that would make it similar to engineering?
(I think thousands of people must have asked/worked on this very question.)

Anyway, this is what Dijkstra had to say about it: (excerpt from https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html )

A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".

[wnorcott]

If a person earns an MIT degree from the Electrical Engineering & Computer Science  department, is that person not  entitled to call himself a 'software engineer'?

By the fine sieve some are using, electrical engineering is barely engineering either.

  Parts machined on lathes? PCB fabrication? That is mechanical engineering.  Only mechanical engineering is a fundamental engineering discipline, which spans millenia. Civil engineering get a nod but is a mere offshoot of ME.   The Apollo program was 95% ME and 5% EE.  As soon as we talk about electronic devices that operate above room temperature, the topic becomes heat transfer, which is also mechanical engineering. Aerospace engineering?   OH, you mean Fluid dynamics.   Designing wind powered electric generators?  Fluid dynamics.  That is mechanical engineering.  Want to bring that widget off the bench and put it in an Abrams tank?  Ruggedized?   Ergo stress analysis, which is mechanical engineering.

[cliffyk]

Yup--MIT, my (alma mater: MSME '71) does not seem to have a problem with it:

[cliffyk]

RAD (Rapid Application Development); when done properly, which I despite 50+ years in data systems engineering have yet to see¹, is as much "engineering" as anything:



-----------------------------------------------------
¹ -- the various attempts i have seen have all gotten to the User Design stage and then gradually (or even rapidly in one instance--an accounting system for a larger State) devolved into "waterfall" projects. It takes far too much discipline (a word engineers know all to well) to stay the RAD course...

[magic]

Okay, I will take the bait

microcoded processors - is the microcode hardware or software
Of course software.
how intel can issue bugfixes to its x86 processors that are installed on motherboards in customers premises
Because the CPU runs software, duh. Or by recall, like the FDIV bug.
whether a finite state machine specification (e.g. to control traffic lights) is hardware or software - or both or neither
Some pedants could argue that a spec is neither, unless in some formal executable language, then it's software.
is someone implementing a function in an FPGA a hardware or software engineer
Most likely hardware engineer, because software engineers rarely know how to produce this particular piece of software.
That being said, I have heard work is under way to make FPGA programming more "inclusive" for code monkeys.
is someone implementing a DSP function a hardware or software engineer
I sure hope he's the latter
is someone implementing a mechatronic product a hardware or software engineer
No idea what that is, meh.

 

[tggzzz]

Okay, I will take the bait

microcoded processors - is the microcode hardware or software
Of course software.

No, since the microcode defines the ISA, amongst other things. As wackypedia puts it:  "Microcode is a computer hardware technique..." https://en.wikipedia.org/wiki/Microcode

how intel can issue bugfixes to its x86 processors that are installed on motherboards in customers premises
Because the CPU runs software, duh. Or by recall, like the FDIV bug.

No, they issue microcode updates which change the processor's capabilities and operation. They would have made it unnecessary to recall processors because of the FDIV bug.

whether a finite state machine specification (e.g. to control traffic lights) is hardware or software - or both or neither
Some pedants could argue that a spec is neither, unless in some formal executable language, then it's software.

I wondered if someone would pick up on that, but it would be more enlightening if you addresses the substance of the key point.

is someone implementing a function in an FPGA a hardware or software engineer
Most likely hardware engineer, because software engineers rarely know how to produce this particular piece of software.
That being said, I have heard work is under way to make FPGA programming more "inclusive" for code monkeys.
is someone implementing a DSP function a hardware or software engineer
I sure hope he's the latter

Which is more likely to understand, say, a Chebyshev filter, a digital PLL, an IQ modulator, a Viterbi decoder, Kalman filters etc.

Not a software engineer.

is someone implementing a mechatronic product a hardware or software engineer
No idea what that is, meh.

Google is your friend: https://en.wikipedia.org/wiki/Mechatronics

[magic]

To me the distinction is really simple: if you can crash your foot with (a sufficient quantity of) it, it's hardware. If you can get it from the 'net without involving Fedex, it's software
There are things which are neither but I doubt anything is both.

By your logic JRE is hardware

And I appreciate the irony of using wackypedia as an authoritative source while calling it out for what it is

[tggzzz]

To me the distinction is really simple: if you can crash your foot with (a sufficient quantity of) it, it's hardware. If you can get it from the 'net without involving Fedex, it's software
There are things which are neither but I doubt anything is both.

By your logic JRE is hardware

And I appreciate the irony of using wackypedia as an authoritative source while calling it out for what it is

Ah. The Humpty Dumpty definition of words. That's all very well until you want to communicate with other people. Maybe you don't want to communicate?

Your JRE and wackypedia straw man arguments are bizarre.

It would also help if you addressed the substantive points.

[Mr. Scram]

Where do these people designing equipment find the nerve to call themselves engineers? I bet most have never worked on an engine or driven the locomotive of a train. Sitting in an office fiddling with numbers is nice and all but we know who the real engineers are.

I doubt the applicable group came up with the term. These generally seem to be made up by HR departments trying to upsell not too glamorous positions. The world is forced to play ball as the original terms deflate as a consequence.

[Scrts]

Is it me only that think "programmer" is a tool (think of hammer) to program a chip or a memory device and the discussion here is about software engineer? E.g. hardware engineer does lots of schematics engineering as well and sometimes none of actual hardware, which is handled by SMT machines and technicians if needed. Debug and validation activities excluded.

[soldar]

I have no problem with software people calling themselves engineers.

The etymology of engine and engineer is from Latin "ingenium" meaning talent or device product of talent, intelligence. In Spanish the word "ingenio" still has both meanings, "clever" and "engine" and you can see they are related in the sense that an engine would be invented by someone with ingenuity, someone ingenious. If someone designed an ingenious solution to a problem of any kind, or he invented a clever joke or play on words, then he is ingenious.

[Nominal Animal]

I've never considered myself a software engineer, but I do apply engineering principles to software design and implementation.

By engineering principles, I mean science on the theoretical side, experience on the practical side, and rational thinking (AKA reasoning) between the two.

[SiliconWizard]

I've never considered myself a software engineer, but I do apply engineering principles to software design and implementation.

By engineering principles, I mean science on the theoretical side, experience on the practical side, and rational thinking (AKA reasoning) between the two.

That sounds like engineering principles indeed. Unfortunately, I tend to agree with Dijsktra's point, which I think still holds true. What we commonly call "software engineering" these days has not much to do with what you just said above. I think the main part "borrowed" from general engineering is more like project management principles (writing specs, choosing solutions, implementing, version control, testing, meetings  ) than anything else. I think there is actuallya lot less "science" used in day-to-day software "engineering" than in any other engineering field.

Of course the question is with the term, discipline and practice of "software engineering" in general. Lots of people are writing software with engineering principles, and at least with embedded software, completely tied to other engineering fields.

[tggzzz]

I've never considered myself a software engineer, but I do apply engineering principles to software design and implementation.

By engineering principles, I mean science on the theoretical side, experience on the practical side, and rational thinking (AKA reasoning) between the two.

I am always dismayed by people who loudly proclaim that only theory/practice (delete as applicable) is necessary, and that the other is bunkum. You need both!

Nonetheless there are probably more cargo-cult software writers than hardware creators.

[magic]

It would also help if you addressed the substantive points.

Nothing can help because I don't think it's a serious discussion

But if you want me to honestly elaborate on your errors,

how intel can issue bugfixes to its x86 processors that are installed on motherboards in customers premises
Because the CPU runs software, duh. Or by recall, like the FDIV bug.

No, they issue microcode updates which change the processor's capabilities and operation.
They would have made it unnecessary to recall processors because of the FDIV bug.

This is exactly what I said, the CPU runs software so they send you a different software if something goes wrong. Kinda like firmware update to your cloud toaster when it kernel-panics on attempt to join your WLAN so you can't eject the toast.
And yes, a microcode update would allow the FDIV bug to be fixed, if that stupid lookup table in the FPU were turned into SRAM. Which is more die area and power consumption in an already hot and crowded subsystem, so I totally doubt that anyone does it in practice. But modern x86 is of course not something that's going to appear on zeptobars tomorrow so we may inconclusively argue about it until death parts us.

I wondered if someone would pick up on that, but it would be more enlightening if you addresses the substance of the key point.

You ask me to stop nitpicking about formal languages and say once more that a description of some FSM, uploadable to some hardware for execution, is software?

[hamster_nz]

Stack Exchange snippets are the programmer's equivilent of an AppNote reference circuit design and PCB layout.

[tggzzz]

It would also help if you addressed the substantive points.

Nothing can help because I don't think it's a serious discussion

But if you want me to honestly elaborate on your errors,

how intel can issue bugfixes to its x86 processors that are installed on motherboards in customers premises
Because the CPU runs software, duh. Or by recall, like the FDIV bug.

No, they issue microcode updates which change the processor's capabilities and operation.
They would have made it unnecessary to recall processors because of the FDIV bug.

This is exactly what I said, the CPU runs software so they send you a different software if something goes wrong. Kinda like firmware update to your cloud toaster when it kernel-panics on attempt to join your WLAN so you can't eject the toast.
And yes, a microcode update would allow the FDIV bug to be fixed, if that stupid lookup table in the FPU were turned into SRAM. Which is more die area and power consumption in an already hot and crowded subsystem, so I totally doubt that anyone does it in practice. But modern x86 is of course not something that's going to appear on zeptobars tomorrow so we may inconclusively argue about it until death parts us.

I wondered if someone would pick up on that, but it would be more enlightening if you addresses the substance of the key point.

You ask me to stop nitpicking about formal languages and say once more that a description of some FSM, uploadable to some hardware for execution, is software?

It is clear you have absolutely zero understanding of what microcode Is and isn't. I suggest you look at the AMD 2900 series and Intel 3000 series processors, and try to understand how to use them. Start by telling us whether they are 2/4/8/16/32/64 bit processors.

Hint: I once designed a 2900 based machine that wasn't a processor in any conventional sense - it had zero RAM.

As for FSMs, what makes you think they are a software or electronic artifact?

I once wrote a report on whether an FSM implemented in logic running at 4000psi should be replaced by a micro. Conclusion: no.

[tggzzz]

Stack Exchange snippets are the programmer's equivilent of an AppNote reference circuit design and PCB layout.

... Only on a good day!

Mostly they are only suitable for "which button do I press?" questions

[Cerebus]

I once wrote a report on whether an FSM implemented in logic running at 4000psi should be replaced by a micro. Conclusion: no.

<Chuckle>

I've occasionally threatened some computers with being reprogrammed with a pipe wrench...

It's probably worth pointing out at this juncture that the first computer programmers did their programming by making changes on plugboards.

[Nominal Animal]

What we commonly call "software engineering" these days has not much to do with what you just said above.

Perhaps; I'm just a stickler on labels, and refuse to call script-kiddies "programmers", or "contractors" substituting toilet paper for wall insulation "professional builders".

It is certainly true that most of the software you'll ever encounter is utter shit.  The "this will probably blow up in your face when you are most vulnerable to failure" kind of ineptitude.
Over the entire globe, most who throw code together aren't even programmers, just aggregators hoping for the best.

I refuse to call anyone a software engineer, if I have seen them produce the kind of spit-and-bubblegum aggregations of code that I encounter daily.
I much prefer to check if they have the ability to do better; if not, then gently suggest they learn, with useful pointers.  If they refuse to learn, claim they just need to fulfill their current deadline and will do better in the future; or if they do have the ability and just didn't, I shall berate their asses off, calling them the lazy cheating fucks they are.  If that makes me an asshole, I'll gladly be one.  I do expect/wish the same from others, BTW.

(Above, I'm referring to my behaviour out and about in the world, not in a workplace.  In a business environment, one should not and does not need to be an asshole, just have some authority over the devs compensation, to get the needed results.)

[Mr. Scram]

It is clear you have absolutely zero understanding of what microcode Is and isn't. I suggest you look at the AMD 2900 series and Intel 3000 series processors, and try to understand how to use them. Start by telling us whether they are 2/4/8/16/32/64 bit processors.

Hint: I once designed a 2900 based machine that wasn't a processor in any conventional sense - it had zero RAM.

As for FSMs, what makes you think they are a software or electronic artifact?

I once wrote a report on whether an FSM implemented in logic running at 4000psi should be replaced by a micro. Conclusion: no.

Is report writing engineering?

[SiliconWizard]

What we commonly call "software engineering" these days has not much to do with what you just said above.

Perhaps; I'm just a stickler on labels, and refuse to call script-kiddies "programmers", or "contractors" substituting toilet paper for wall insulation "professional builders".
(...)

Oh, I agree with the above, but just OTOH to make things clear: just because we are debating whether software engineering is really engineering (again, something that has been debated for decades, nothing new or particularly horrible to discuss), doesn't mean that software developers are "less" than engineers in general (some can be, but some "engineers" can be real bad too). We're not questioning the value of people writing software. Just whether engineering is the right term to describe software development, why, and what the consequences can or can't be.

As I said above, I personally think "software engineering", in the past decades it has been called so, has focused too much on project management methods and maybe not enough on the fundamentals, which has led to much more repeatable software development processes, and has made it easier to hire and integrate software developers in teams, but has not necessarily hugely improved software quality all in all.

[Cerebus]

Is report writing engineering?

Only if you do it in crayon. 

[tggzzz]

It is clear you have absolutely zero understanding of what microcode Is and isn't. I suggest you look at the AMD 2900 series and Intel 3000 series processors, and try to understand how to use them. Start by telling us whether they are 2/4/8/16/32/64 bit processors.

Hint: I once designed a 2900 based machine that wasn't a processor in any conventional sense - it had zero RAM.

As for FSMs, what makes you think they are a software or electronic artifact?

I once wrote a report on whether an FSM implemented in logic running at 4000psi should be replaced by a micro. Conclusion: no.

Is report writing engineering?

It is frequently the deliverable result arising from engineering judgement.

[Nominal Animal]

As I said above, I personally think "software engineering", in the past decades it has been called so, has focused too much on project management methods and maybe not enough on the fundamentals, which has led to much more repeatable software development processes, and has made it easier to hire and integrate software developers in teams, but has not necessarily hugely improved software quality all in all.

True.

I do not think that most software development can be called software engineering, or that most programmers are software engineers, simply because they do not apply engineering principles in the development work; that is, that developers don't apply engineering principles to their work, only to their process.  (Which, I think, is basically what you are saying above.)

Just like Scram's question above, "Is report writing engineering?", the devil is in the detail: it depends on how you construct the content.
If you wing it, or "I know this stuff like the back of my hands", no, it isn't engineering, it is just writing out ones understanding.

You do not apply engineering principles when writing.  But, to find out what you need to express, and how to express it, you can apply engineering principles.  I often do, many don't; but like I said, I do not consider myself an engineer.