[jerf]

I've developed a real distaste for the people whining about how we aren't real engineers and we "just" need to solve that by working more like real engineers and having all these massive up-front design meetings and making tons more plans, etc. etc.

It betrays a profound misunderstanding of the situation. The other engineering disciplines don't work like that because they're just soooo much more professional than us. They don't work like that because it is a better way. They work like that because for them, it is the only way. You do not build a hotel, and then realize the ceilings need to be six inches higher, and tear the whole thing down and start over.

If they could work by running ceilingHeight += 6 and hitting "Rebuild", see the hotel rebuilt and the automated unit tests automatically double-check the usability of everything inside for handicapped people etc., all for a grand total of about $2.82, they absolutely would.

Shed your inferiority complex. We are not squalling babies drooling on our blocks while Real Men (with all the pejorative connotations modern political sensibilities see in that term fully intended) are building bridges and dams. We engineer with better tools than they could dream of having, and it's completely expected that that results in highly significant changes to our processes.

Do we sometimes fail to bring enough process to a problem? Yup. But if you think that's a problem unique to programming, I prescribe to you spending several hours with https://www.imdb.com/title/tt4788946/ .

[zemvpferreira]

I might be misreading but I think you're missing the forest for the trees. It's not about the upfront planning, meetings or whatnot, those are consequences of prior criteria. This is what engineering is:

1-A practical problem is being solved in a scientific way.

2-Safety, repeatability, understanding of the how and why of the solution are non-negotiable.

3-The person solving the problem has been credentialed as an engineer in both ethics and scientific rigour.

4-Because he is credentialed, there is non-waivable liability for the engineer signing off on the solution if it fails.

No whining or superiority intended, but if any of the four criteria is missing, you're not practicing engineering. In my experience most software development is missing all four. That's not necessarily a bad thing, it's just that most software development isn't engineering.

Again, nothing intended by it. There's no superiority to engineering over development.

[javawizard]

My bleeding linguistic descriptivist heart breaks a little every time I see an argument devolve into squabbling about the meaning of the word "engineer". Like, we can totally debate the merits of applying or not applying those four rules to the practice of creating software, but do we really gain much by arguing about what label we use to represent them?

It's like how the word "literally" has come to be used as an intensifier, not strictly in the (ahem) literal sense of the word - and "objectively" is well on it's way down the same path. You can be angry about that, but it's not going to stop the continuing evolution in how the world uses those terms - and "engineering" as a term is exactly the same.

[kortilla]

> 3-The person solving the problem has been credentialed as an engineer in both ethics and scientific rigour.

>4-Because he is credentialed, there is non-waivable liability for the engineer signing off on the solution if it fails.

Both of these are bullshit. The engineers that aren’t yet credentialed but do all of the work that the PE signs off on are still certainly engineering.

> 2-Safety, repeatability, understanding of the how and why of the solution are non-negotiable.

Safety critical systems would like a word.

[rockemsockem]

Many engineers are not credentialed by any government body. IDK what the breakdown is, but the engineers who build rockets and design a lot of new electronic devices have none of this. And the world is better for it

[gretch]

I completely agree, it's 2 separate mediums with their own optimized process/technique.

It's like sculpting Clay vs Marble. If you make a boo-boo in clay, it just takes you a second to readjust. If you are working in Marble, and you took a piece out that you weren't supposed to - well it's time to order a new marble block.

Taking the techniques and processes of marble sculpting into the world of clay would just make you a bad (or at least highly inefficient) clay sculptor.

And there's really no point to a dick measuring contest of whether clay or marble sculpting is more worthwhile - they both have their own place in our society.

[javawizard]

Total tangent - one of the things I love about 3D printing is that it's about as close to "ceilingHeight += 6" as you can get in the real world.

Case in point: I modeled a thing today, printed it off, and realized that it would be ever so helpful if one part were about a millimeter thicker. 30 seconds later, version 2 of the part is on its way to the printer.

It's fucking _amazing._ I can't wait for stuff like that to become as mainstream as paper printers are.

[yen223]

I think people who think software engineering isn't real engineering, will be shocked at how much "real" engineering is just people plugging numbers into software

[antod]

Yeah, in my experience, the real world engineering was rushed, under funded, relied on gut feel, and could count on the humans on site building it to use their own judgement to make up for all the gaps in the designs, drawings or specs.

Although back then in the 90s it was plugging numbers into tables rather than software. Very little science involved in any of it.

[rockemsockem]

Big time. Some folks on this site have serious "grass is greener" issues.

[dudeofea]

you can certainly fix an engineering design in-situ, just look at all the airplanes/jets designed pre-CAD software that were made "just-so" with all the know how embedded in the brains of those that made them/fixed them https://www.youtube.com/watch?v=NPVT2lvMvOk

[jerf]

Of course you can... sometimes.

And you can't always do it in software, either. I keep a mental list of "things you can't really retrofit onto a mature piece of software" that I keep kicking myself to turn into a blog post sometime. I suppose a quick & trivial example is that pretty much by definition switching languages involves a rewrite.

(Though that involves a bit of definitional footwork where I declare using a compiler that goes from language A to B isn't really "switching to B". Anyone who has tried that maneuver in real life can attest it certainly isn't the same thing as a real full rewrite in the target language, even if it does sometimes have its utility.)

Still, there's literally orders of magnitude difference in how likely a given retrofit is to work and how easy it is for us to add it, and proof of that is precisely in the enormous signature this difference leaves on our processes.

[4gotunameagain]

  > Shed your inferiority complex. We are not squalling babies drooling on our blocks while Real Men (with all the pejorative connotations modern political sensibilities see in that term fully intended) are building bridges and dams. *We engineer with better tools than they could dream of having, and it's completely expected that that results in highly significant changes to our processes.*

I just want to add, that this comes off as originating from an inferiority complex ;)

Why is the term engineer so important to you ? Just do your job, do it right, and ignore criticism.

[jerf]

I don't have the inferiority complex. I see it in others.

They are, frankly, welcome to it, right up until they try to ruin my job by adding negative-value processes because of their complex.