Software Engineering vs Software “Engineering”

/via http://mibt.edu.au/certificate-iii-in-concreting-cpc30313/

You’ve heard of “concreting”, right? No, I’m not referring to the verbing of the noun “concrete”, I’m actually referring to the construction process around laying concrete. It’s a term of art, referring to getting the concrete as close as possible to its final position, as quickly and as efficiently as feasible, to ensure that it can be fully compacted, and that there is no segregation .

The thing about concreting is, it’s Engineering. You don’t just wake up one day, and say to yourself “yeah, I think I’m gonna pour foundations”, and start doing it. More importantly, even if you were to start doing it, nobody in their right mind would (or should!) actually hire you to actually do it. Most importantly of all, if you’ve come up with (what you believe is!) a new and improved way to pour concrete, the burden of proof is on you to show that it works. And no, this isn’t about the Man keeping you down — it’s about asymmetric risk. The downside risk to going with something unproven (the overpass collapsed killing XXX people) is way, way higher than the upside reward.

/via https://xpressreo.com.au/

All that said, experience plays a huge part in concreting too! Consider the placement of reinforcement steel — that latticework of bars that concrete gets poured around. The steel is all tied together and positioned with tie wires and plastic supports, which should hold things in place. However, when the concrete is getting poured and vibrated and tamped and whatnot, every now and then some of these ties will snap, and one of the bars will pop up insouciantly mocking everyone with it’s gesture of freedom.

The problem is, you can’t exactly remove the concrete, find the broken tie(s), and reattach stuff — the engineer on site typically has to make a judgement call, and figure out where to attach the loose bar. Sometimes it’s an easy call (“obviously the one over here!”), and sometimes, not so much (“whyTF is there even a free bar in this location?”)

And that’s where experience comes in — the more jobs the engineer has worked on, and the more teams they have worked with, the more likely it is that they can figure out the correct patch. Which can be the difference between a successful setup, and one which needs to be dismantled and redone in the future.

Aaaaaaand, see what I just did there in the last paragraph? Notice how this applies exactly as much to deploying software systems successfully as it does to concreting?That, my friends, is the difference between Software Engineering and Software “Engineering”, the latter being the domain of #CowboyDevelopers who are constantly asserting their Dunning-Kruger infused superiority in firm defiance of objective reality.

/via https://consolia-comic.com/comics/house

The presumption in most (all?) other forms of Engineering is that you only get to be one after you’ve jumped through a certain amount of formal hoops. The hoops might be from M.I.T., or from the University of Phoenix — it doesn’t particularly matter, as long as the institution is accredited, the certification is legit, and so forth.With Software, OTOH, the existing ethos is an all too frequent distrust of authority. The Silicon Valley mythos — scrappy startup bootstraps it’s way to success — is way too deeply embedded in our society, and fuses with the Hero’s Journey as well as #TechBro culture in an unholy trinity of disfunctionality.

It’s a lot easier to get hired for coding excellence (“look what I can make python do!”) than for engineering training (“I understand formal methods, but nobody gives a shit”). Once hired, odds are that the n00b goes through training which might involve just throwing them in the deep end, or if they’re lucky, they get paired with somebody senior to learn from. Even if they’re lucky though, the next hire may not be so. And even if they are lucky too, they’re paired with a different senior developer, and the skills, tooling, and experience that each ends up with will be different. And even that doesn’t begin to touch upon human biases (“yes Toto, there may be differences in the way people are treated based on gender…”), situational differences, and so forth.In short, this is not an apprenticeship. We may think it is, or pretend that it is, but it really isn’t.

We need to get a lot more serious about Software Engineering, and treat it as an actual field, not one that we all get to wing it on. More to the point, we need to pay attention to the folks that already do so, and start learning from them. Given the already huge, and still increasing, importance of software in our lives, our futures depend on it!

(This article also appears on my blog)