Calling the discipline Software "Engineering" was the worst thing that could be done, at least given the current state of the art. Because of that, people thought you should write software the way you build a bridge or a car. The waterfall method came out of that, and it took decades to realize and recover.
Software development is more reliant on discrete math (and more generally the ability to reason abstractly) than math that helps model the physical world. Hopefully, Professional Engineering bodies will one day realize this and will adapt their program accreditation criteria accordingly.
"Because of that, people thought you should write software the way you build a bridge or a car."
The reason people think that is because they have no idea how the engineering to build a bridge or a car is done.
Note, the term is Software ENGINEERING not Software Assembly or Software Construction. The engineering work necessary to design a bridge or car is actually not TOO dissimilar to designing anything else. You have requirements (often vague, conflicting and changing) and constraints and you have to trade things off against each other to come up with a workable design solution.
The construction is just the compilation. Or perhaps the final coding/debugging. Or a combination. In construction, tiny engineering issues are often resolved by the construction crew at the site. Sometimes with input from engineers, sometimes not.
The problem is that building software merges the engineering (design/architecture) with the construction (coding/debugging/compiling/installation) that requires a rather broad range of skills. Most people working on small teams have to jump back and forth between the big picture (more engineeringy) to the small details (more constructiony) and back.
Finally, software development is no longer a new thing. People have been doing it for a half century. There are many people in the field today who's parents wrote software. And a few who's grandparents did it. It's high time we stop trying to draw analogies to building bridges or designing cars. Software Engineering is its own discipline with its own unique challenges and dynamics. Better to just take it for what it is.
No the waterfall method was a misquote by a non-tech reading a report on iterative, software development. The misappropriation took a life of it's own for control-freak managers. Anyone wanting an example of where sensible people went with software engineering can look at Cleanroom from the 80's:
The results speak for themselves. A modern approach is Altran/Praxis Correct by Construction method getting nearly zero-defect software. Some provably correct in SPARK.
Today's work can add symbolic analysis (eg KLEE), assertion-driven test generation, languages like Haskell, certified compilers, and so on. What you're seeing in mainstream isn't software engineering. It exists, though, in s niche by academics and industry.
On the contrary, the worst thing was the abandoning of the sound engineering principles and the obligatory professional certification. Since then, the trade has been open to, and flooded by, know-nothing lazy half-wits who, should they find themselves in any other industry or medicine, would be immediately disqualified (or, rather, would not be admitted in the first place).
Mainstream engineering and certification developed thanks to litigation, insurance, and regulation. These are things that we don't have in the software industry yet. UL is called "Underwriters Laboratories" for a reason.
I work in product development, and when we send a product out for certification, they don't look at functionality, but only safety and regulatory conformity. Is the grounding wire green with a yellow stripe?
But it would be interesting for the rest of us to have an overview of how software is done in those fields. i'm guessing that those are also areas where litigators have refined their ability to prove fault and quantify injury in dollar terms.
> Since then, the trade has been open to, and flooded by, know-nothing lazy half-wits
In other words, web "devs" who are now calling themselves "full" "stack" and flood all walks of software development with subpar nonsense in the name of silly startup "mvp".
But do we mean quality and usefulness as technical attributes of a program's construction at a point in time?
Or as beliefs of a customer about a product, or a company?
The skills to get to the latter are often different to the first, and both are expected in many modern software engineers. The later is much more about iteration, experimentation, empathy, and judgement. It's not worth polishing areas of a system which you anticipate abandoning based on the results of an A/B test. Writing it and abandoning some meh code can still be the best engineered choice in a product development process.
The engineering of the development process matters more than the program.
I'd argue that success in modern software engineering (at least in Silicon Valley) is at least as dependent on understanding social processes, as it is on computational ones.
Oddly enough I think there's an analogy in mainstream engineering. If you build a supermarket, it has to be engineered for safety. But the engineers are not responsible for whether the mall serves a purpose, such as selling products for money.
Because the market is still paying for software licenses instead of paying for services. It rewards writing as much code as possible to sell it. And then deprecate it and write more and more.
While I totally agree with you on the 'it's not engineering in the engineering kind of sense'-part, there's another interesting point a friend once brought up in conversation:
At least where I'm from, telling people what I do, I often get labeled as a 'computer person'. You know, kind of estranged from the real world and not good for anything practical (and mind you, after college I shed a lot of my admittedly nerdy past). Coining the term 'software engineer', with the word 'engineer' being something people can relate to and see it as a respectable profession, I think can help a bit in conveying that yes, what we do is a real and important job and no, we are not all geeks that totally like to be in their dark basements all day.
Software engineering is no less 'engineering' than, say, designing computer hardware - if anything, simply because there is often a piece of software hiding inside a microchip, but also, more generally, because the process of logical design of digital electronics is not much different from writing a program - especially if it is designed using what is essentially a programming language (Verilog, VHDL, etc.).
If you write software that needs discrete math, like probabilistic stuff or graphs, it will need discrete math. If you write software that is meant to simulate, like maybe even simulate real bridges, or video games, or generative art, non-photorealistic rendering, ... it will involve some of the math that helps model the physical world. It makes more sense to just learn a lot of things and apply the union of that to software, even ideas surrounding managing complexity in architecture (Notes on the Synthesis of Form?) and so on and expose that through oneself to "software" as a new universe where creations can exist; than to quibble about what's more important and what's not in a prescriptive way about what others want to and don't want to do. Of course, I'm doing the latter here. :) Such is the cycle.
Software crafting is very much like building a bridge back in the days before xrays were around to detect cracks in metal and before metallury and casting were very reliable - that was back in the 1800s when anything made of metal could and did fail at any time - including bridges - quite often catastrophically. A high percentage of bridges folded, over time. How do you "engineer" what you can't measure (such as whether a metal beam is fatally flawed by a large crack inside?) You don't. We're getting there slowly.
A big reason for that is that projects, tasks and estimates are a hell of a lot easier to tack dollars onto than "sprints."
A big part of Agile is "We think this story might take x, but it can take x+y divided across 2n weeks of progress." Unless you have a PMO that can say "Okay, fine, but we're giving you $x to do it, manage it yourself," you'll always fall into waterfall because y is too difficult to financially forecast.
Rally by CA Technologies "solved" for this and gained lots of enterprise adoption somewhat quickly by trying to tack dollars onto sprints; from what I've seen, this essentially created a "scrumerfall" culture where teams have sprints with stories ("functional requirements") that come from epics ("design requirements"), but everyone has tasks and they'd better be estimated with hours.
This is what "Lean Enterprise" tries to address. PMOs should use data from their customers to drive their projects, and projects should be "invested into" instead of "estimated and rationed."
I don't know if it was the worst thing. I agree that it was unfortunate for the one reason you gave (waterfall), but there are other reasons that a new discipline(/profession) would want to emulate the practices of an older and more established discipline.
Another reason to choose "engineering" was to encourage software practitioners to incorporate some of the proven methods of traditional engineering. As an example, I've noticed recently that ethics training is an established part of an Engineer's education, but not so with Software "Engineers".
There is always room to improve, and I don't think ignoring the past, and justifying that ignorance by saying "but we're different" is necessarily the best way to achieve that improvement.
Software development is more reliant on discrete math (and more generally the ability to reason abstractly) than math that helps model the physical world. Hopefully, Professional Engineering bodies will one day realize this and will adapt their program accreditation criteria accordingly.