I think the term "software engineering" sometimes does more harm than good. Because we call it engineering, we tend to act like it's a rigid, well-defined discipline...like civil or mechanical engineering...where things have precise definitions and there's a right way to do everything. But in practice, software is full of gray areas. Take testing: people argue intensely about what counts as a unit test vs an integration test vs an E2E test, as if there's some pure Platonic definition out there. The same goes for debates about microservices vs. monoliths, service-oriented architecture, and so on. The energy behind these arguments often feels religious, not practical.
Over time, I've found that the only reliable way to reason about engineering decisions is to work backward from the business use case. What are we trying to accomplish? What's the time frame? What risks are worth taking now vs later? Everything else...patterns, paradigms, "best practices"...only make sense in that context. The rest is academic, and often divorced from reality tbh.
Also noticed that many strong opinions in engineering come from people trying to avoid pain they've experienced before. But the solution that saved them in one situation can easily become a liability in another. Patterns ossify into rules. That's why I try to keep my reasoning grounded in outcomes and context, not ideology. Most "best practices" are just local maxima..useful until they arent.
For example, there's probably an under-regognized amount of materials work going into radiation shielding related to current fusion efforts. And there's a huge amount of, perhaps subtle, material science innovation going int consumer products and elsewhere,
Same for electrical engineering. Some solutions require as much creativity and have infinite possible solution as software does.
The main difference is that most people working in electrical or electronic engineering aren't being forced to ship half-working products that might change tomorrow. When we ship a product, it's "done". The cost of modifying it later is not zero. Well, the same is true for software, but this is a reality that business gaslights developers into ignoring.
It’s a we can always fix it in post-production which becomes less and less the case with many physical projects. But that’s at least somewhat different from there not being fairly established ways of doing many fundamental things and having best practices for testing etc.
That flexibility is a fantastic advantage of software over hardware, not a liability. You still can deliver software as an unchanging thing, but generally no one does because incrementally giving users something useful sooner is more valuable.
Depends how you use that flexibility. If it’s to add capabilities and fix minor problems that all products have, sure. If it’s to ship bug-ridden crap just because it can probably be fixed later, I’m less of a fan.
Theoretically, it could have been an advantage, but in practice it's not. What we got instead is a software ecosystem of slow, bug infested garbage that requires constant updates.
I agree that we don't live up to the title of "software engineering", and it's not a mistake that software is uniquely complex, but all the same this advanced degree of complexity doesn't preclude a culture of engineering. See the user and know your abilities (including limitations). That is what engineers are called on for. And when ethics comes knocking, know that there are not just users but stakeholders.
I should say that software complexity is different than normal engineering complexity; physical constraints are replaced with cognitive constraints on managing abstractions. To address both: designing a modern microprocessor is very complex. I think certain software tools used to aid in this, e.g. a simulator to test designs, are very complex. These complexities are different: the former is based in science and the latter is based in logic. Even so, they intersect in the real world, but aren't equal. I think the latter has a much higher ceiling for difficulty, as complexity comes for free there.
The power of software is how it 1) moves a lot of work from the domain of the physical to the domain of the written and intellectual and 2) the way it can be replicated at scale. So it really isn't like engineering, more like writing, but industrialized. Well, at the application level at least, where a lot of software work happens. The work that actually allows written software to physically interact with the machines it runs on, that's engineering, but generally not what most "software engineers" work on.
Anyway, it's not really so surprising that there are few hard and fast and replicable rules in "software engineering" as there really aren't in, say, essay writing. There are best practices and tips and techniques that are generally more effective than others. And there _are_ actual constraints around software that don't exist around essay writing as, ultimately, software does have to translate to real physical limitations like available memory and such, but the abstraction away from those physical limits is by and large the point and purpose of software.
As an experienced "software engineer" :D, I fully agree with you. Although I would phrase it differently.
All patterns & practices come with their benefit and drawbacks. So all decisions are very much dependent on the circumstances. This is what you called "local maxima".
What separates software from engineering are concerns about legal liability. If we actually sued software companies for shipping us harmful crap, software would start to look like any other kind of engineering.
Not really true. The legal liability is generally associated with the Professional Engineer designation. In electrical engineering, for example, my experience is that almost no one uses/needs to be a PE unless they work in infrastructure projects like power distribution. People designing PCBs, ASICs, etc going in consumer products aren’t generally PEs.
There isn’t even a software engineer PE any longer I believe. But even otherwise it’s uncommon outside of civil engineering. Mostly it’s for signing off on drawings/designs for regulators.
I started down the path in mechanical but didn’t stay in that track long enough to get one.
I agree strongly with your second two paragraphs, but I'm going to push back on the oft-repeated meme that software engineering is not real engineering because it doesn't have the same disciplined approach as physical engineering practices.
Personally I think software engineering is absolutely engineering, it just has mostly different constraints from physical engineering. Most of this has to do with the dealing with the costs and consequences of building things in the physical world. Without those disciplines, a huge capital cost goes into building a bridge that fails, or an expensive machine that can't do its job. We also have to account for the limitations of physical materials and a harsh environment, which are in some ways harder to account for, but also more stable as a well-understood substrate than pure software (ie. all animals have some intuition about physical things, physics doesn't change, materials capabilities change slowly, etc).
When folks lament the lack of "discipline" in software engineering I think it's a misplaced, grass-is-greener sentiment that hasn't really been thought through. The reality is software has different constraints, not harder or easier, just completely different apples to oranges differences. For instance, durability and maintenance in physical objects is about material properties and physical wear and degradation from the operating environment, whereas software bits are infinitely durable and replicable, but they get broken by the environment itself since they have to interact with thousands or millions of other software artifacts created over many decades. With physical engineering it's mostly about discrete objects with natural and intuitive encapsulation that are in a sense "immutable". Some software is like this (like pre-internet console video games shipped on cartridges), but typical cloud-based software is nothing like this, it's a constantly evolving tangle of interconnected logic and ever-growing data used for widely heterogenous purposes, often never fully understood by any one person or entity.
This messiness is one of the frustrating things about software, but it's also its strength. Anyone that tries to declare rigid civil-engineering-style discipline to software will not survive in the marketplace because most software is not life-or-death. The discipline put into the Mars Rover or the Therac 25 successor would simply be overkill for average software. That said, of course there are cases where the importance and impact of software correctness is unknown, like if the government were to start using social media sentiment to impose real-world consequences on its citizens, but these types of considerations are much more fluid and harder to nail down than physical properties like "will this bridge stand up for 50 years". Software engineering in my view, is about leveraging the malleability of software to solve problems in a constantly evolving landscape. We're not just standing on the shoulders of giants, we are directly calling their APIs to solve new problems they couldn't even have conceived of. One could argue this is too broad to really be "engineering", but I can't think of a better word to describe the highly technical process of understanding and solving problems with software.
Could it be that not all software development is equal? Some of it leans more towards engineering and the academic (e.g. compilers, operating systems, tpc/ip stacks, etc) vs software that leans more towards the creative (e.g. web and mobile apps, games, api's, etc). I.e. to me software development seems more of a spectrum.
My take would be that “they” are all of the people for whom learning to program gives a false sense of overall ability. It doesn’t follow that building a solid software product means you know how to build bridges, or fix social problems. But “they” seem to think it does. A tendency among the very young perhaps, but the hubris of the technogist is widely remarked upon.
There was a time when all the people who would be electrical engineers were basically tradesmen. In the US, mostly trained by Edison. They were called "muckers."
Until recently most of the people calling themselves SE hate code monkeys and their attitude. Which is a lot of the impetus to call yourself something else so as not to be lumped in with the sloppier elements.
I've often felt that coding is more akin to writing than anything. Any given statement is perhaps mathematical but at the higher level you're more authoring a program according to humanistic needs and thought patterns rather than strictly "engineering" it.
Over time, I've found that the only reliable way to reason about engineering decisions is to work backward from the business use case. What are we trying to accomplish? What's the time frame? What risks are worth taking now vs later? Everything else...patterns, paradigms, "best practices"...only make sense in that context. The rest is academic, and often divorced from reality tbh.
Also noticed that many strong opinions in engineering come from people trying to avoid pain they've experienced before. But the solution that saved them in one situation can easily become a liability in another. Patterns ossify into rules. That's why I try to keep my reasoning grounded in outcomes and context, not ideology. Most "best practices" are just local maxima..useful until they arent.