Is Software Engineering Real Engineering?

Software has a magical property that other engineering disciplines do not: The engineering environment is ideal and fundamentally perfect. It's like building electronic circuits but only in the simulator that uses all idealized parts. And you get the extremely rapid prototyping and scaling that comes with that. (A "single line of code" equivalent error in a production analog circuit can take months to fix and years to distribute)

In a way it feels "unfair" because the fuckery of mother nature and immovable boundaries of physics is largely (and normally completely) cut out of the equation. Imagine having to write code where every variable is a fuzzy range as opposed to a fixed value, it would put a huge clamp on designs.

However,

The intellectual savings from not having to deal with non-linearities and errant physical effects, is largely just shifted into increased overall complexity that all exists in a different realm. So maximum logical thinking and intellect is still demanded.

I think the divide really comes from the difference in space in which the "engineering" is happening. Conventional engineers are dealing directly with nature trying it's best to constantly break your design. And I think there is a degree of comradery that comes with that. Software guys, free form those chains and working in a parallel universe of perfect logic, instead are pushed to the absolute limits of complexity.

What I mean is imagine if a car company found a defect with their cars, they would have to issue a recall and update their vehicles, a long an expensive process. The key difference is with SWE, we can just push an update and have the thing fixed, there are many possible scenarios here but overall even if you had to push a patch to customers that are running in an air-gapped env, even that would be easier than a traditional recall in engineering. For me this single fact changes the entire dynamic of SWE compared to traditional engineering.

In traditional engineering you can't simply put up a bridge that would support 500 cars and say "oh we'll update it to support 5000 cars down the road", but you can totally do that with SWE application that can only support X number of users at the start but plans to scale up to support more. This thinking of "we can address this down the road" affects practically every decision in SWE compared to traditional engineering outside of specific cases.

Every engineer deals with constraints and finds ways around those constraints. SWE has a set of constrains that is very very different from virtually all other engineering disciplines, and for that reason you get the constant question of whether SWE is even real engineering.

If other engineering fields had metaphorically similar costs and benefits to software, their procedures would look like ours. If they could flip a flag to change the color scheme on their hotel and push the "compile" button to tear down the entire previous hotel and build a new one in 30 seconds, they would not be using blueprints and carefully planning their every move. They'd incrementally build a structure just like we do, pre-existing libraries, iterative development, the whole thing. They don't not because this is not engineering, but because they can't. You can't afford to have an inspector come in at the end of their project and announce that the ceilings are 6 inches under code and the whole thing is condemned.

I find the occasional moon-struck love affair with other engineering disciplines and how they're doing real engineering and aren't they just so dreamy to be badly misplaced. They would be jealous of us, if they knew what we had. They're doing real engineering. We're doing real engineering. The people not doing real engineering are the ones who blindly copy inappropriate methodologies from other engineering disciplines, which is the engineering methodology equivalent of writing object oriented code in Haskell. Building a program like it's a skyscraper and we must plan our every line of code, which we can place only once, and it must be perfectly correct, six months in advance, is as inappropriate as trying to build a skyscraper through iterative development.

- The blue print analogy is used a lot to argue why software engineering isn't real engineering. The reasoning goes like this: you create a blueprint of something like a bridge and you don't start building the bridge until the blue print is done. Then the bridge building process is reasonably predictable and structured because you already solved all the problems. If only software engineering was that predictable. Of course with software, the process of creating the blue print is literally creating the software. The build step tends to be fully automated (compilation). Blue prints for your blue prints used to be a thing when we had waterfall. Creating a blue print for a bridge or a nuclear plant is similarly less predictable. Because that's where you have to do all your problem solving. That's why so many of these hard engineering projects go way over budget.

- SpaceX is using rapid iterations with rocket design. This is real engineering but they are also doing things that come directly from the agile world like not trying to design the entire rocket waterfall style, failing, and then spending another five years fixing the design. Instead they iterate rapidly, go through lots of prototypes and iteratively refine the rocket.

So, it's not that black and white. The process of creating good blueprints on a predictable schedule is not a solved problem. Also not in hard engineering projects. Using agile methodology and testing your blueprints in either simulated or real form helps.

I didn't listen to the interviews but, as a pure software person I've observed the following:

1. Most software 'engineers' are more like technicians, plugging libraries into each other

2. A very small subset of software writers are in fact doing real engineering

I'm working with a semiconductor company at the moment, with traditionally trained engineers, many of whom are 25+ year vets from industry and academia. Semiconductor design makes most software 'engineering' look like children playing with safety scissors. In silicon, the bar to ship is nothing short of literal perfection. When's the last time you shipped a software project with 0 known bugs, spent tens of thousands of hours on testing (design verification), and improved on the best-yet-achieved-by-humans performance by 2x - 5x? Never? Same.

It seems to me the reason this question gets asked is due to the massive gulf between software and other engineering disciplines in terms of the level of rigor and correctness brought as table-stakes. As others have pointed out, software has the luxury of being able to hotfix bugs (correctness, and performance) after release. This has led to most of our industry being extremely sloppy, lazy, and frankly kind of embarrassing. Software shipped today is dramatically less efficient, more buggy, and sometimes even less useful than software shipped just 10 years ago, let alone 15 or 25.

I don't have a solution for this problem, but I hope we can one day hang the big-engineering-boys-and-girls, and, ship quality software again.

When you engineer a bridge, there is a use case such as light vehicle traffic. That translates to a load requirement to achieve that goal. Your design must then guarantee that it fulfills that requirement.

Success and failure in this environment are defined and objective. Furthermore, you can largely rely on the guarantee being made; the correct operation is well-defined within some meaningful domain. Engineering turns the subjective qualities of a product into objective bars for success.

Specifications generalize this process by providing well-defined guarantees. These can then be used by another to fulfill their requirements.

Engineering rewards results, not efforts. It is about fitness of purpose, not best efforts. It is about success and failure, not how hard you tried.

Even in “traditional engineering” some people refer to certain tasks as “not real engineering”. Usually they are talking with their ego and wish it was the 70’s so they could be drafting with pencil.

Their opinion doesnt mean anything and is basically regressive.

So the idea of if any task is “real engineering” is just such a pointless debate.

Defining any activity as engineering or “not engineering” isn't useful.

Calling yourself a software engineer is fine as a job application tool, but needing to be seen as an “engineer” is just meaningless ego.

Ive seen this debate for over a decade at this point, some like to split developers vs engineers by some arbitrary standards, but honestly it doesnt and has never meant anything.

Software Engineering is real engineering.

Far fewer software engineers exist than software developers who call themselves software engineers.

I have never called myself a software engineer.

Like most titles of prestige, "engineer" has been massively devalued of late by the constant marketing machine.

In the context of being an engineer - it's not. A real engineer's licence can be revoked due to misconduct, is issued by a governing body and carries some weight.

Software developers can call themselves engineers or even Code-Alchemists, but it carries zero weight.

I think what's actually fuzzier is the definition of "real" engineering, whatever the hell that is. I'm not discounting that specific practices within engineering have clear definitions, but there's no one consistent way to lump every one of those professions together and have a cohesive "you're in or you're out" definition.

Coming from a mechanical engineering background, I understood "engineering" as the application of science for problem solving - or, put simply, applied science. Some examples:

1. When a civil engineer applies solid mechanics to select a cross beam. 2. When an electrical engineer applies E&M to design a circuit. 3. When a mechanical engineer applies heat transfer to analyze cooling patterns on a laptop.

Under this definition, most "SWE" work isn't engineering - if anything, it's closer to applied math and logic?

That said, definitions are only useful inasmuch as they allow us to make sense of the world and communicate with others, so I'm not sure this is the most useful question

Most of us empty the trash and change the lightbulbs and think we are structural engineers. I'm ok with what I do, but I don't pretend I'm something I am not.

OTOH, I'd also be lying if I said that there weren't real world benefits to working a little more "fast and loose", and I'm at a point in my career where I can accept that the varying level of rigor and standardization in the more profitable software companies is the best balance in today's world, and I try to pick my battles.

But I don't think this is any more "engineering" than an MBA using spreadsheets and accounting statements to decide where to allocate human or capital resources to maximize profit. We just use a fancier set of tools and have a different domain to optimize.

And I know this doesn't reflect every dev job. But it sure does a heck of a lot of them.

Then I wrote firmware for some devices that was fairly complex and the programming needed to be absolutely perfect to ensure various hardware issues (and product bugs/failures as a result) couldn’t happen.

You wind up creating remarkably stable and thoroughly tested code, both digitally and physically, and the end result is something incredibly precise due to rigorous design and execution both on the software and hardware sides.

That feels a lot more like engineering. I actually miss it a lot. I can’t help but bring a lot of what I learned to usual software development, but I find a lot of people dislike the same kind of rigour and precision. Like it’s in the way of getting things done, and fundamentally that’s all that counts.

I can see why pure software isn’t considered engineering as a result. The “we can push a fix” mentality can seriously undermine one’s care for the work as well as the overall design and testing practices.

In any case, I’d argue it can be engineering, but it often isn’t.

Waterfall and Agile is not Software engineering, I think software engineering is algorithm design, API design and anything design, coding and tooling in general

software project management is .. software business, not software engineering

This allows many organizations to utilize software engineering skills without having any particular mentality towards engineering itself. Some businesses can be arranged such that the software development practice is much like an assembly line, reducing developers to assembly line workers. Some businesses actually use engineering skills and have an engineering mindset.

The fact that businesses can find success while having terrible or no engineering practice is an example of where software engineering differs from any sort of engineering of physical things. Mechanical, electrical, chemical, etc engineering does not have such a tolerance, they simply exhibit failure if so.

I sit in on several different design reviews and it kills me how similar each engineer thinks even with such disparate differences between each discipline.

In terms of difficulty for my smoothbrain to comprehend from easiest to hardest to understand, I'd say it goes mechanical, software, electrical, and then firmware.

Like holy hell, firmware engineering is a dark art. Kudos to firmware engineers.

These analogies are oddly captivating even for those who are very experienced in software but do not have any experience in other problem domains.

I think that while such analogies provide some comfort, we are better off eschewing them completely. In software we need to focus on the actual “mess” in order to begin to draw useful conclusions.

At the end of the day, what is “real” anything? Isn’t this just a form of the “True Scotsman” logical fallacy?

Interfaces matter so components can cooperate but the internals can, and generally should be, treated as a black box. It’s like connecting chips on a board.

The actual code is more like painting a landscape. There are techniques for representing some idea and many can be chosen. It’s up to the artist to choose the one they think works the best.

So long as the interface to the world outside is solid, it usually doesn’t matter what happens inside.

For instance, if I had an interface to write data to a file it may have time constraints. So long as they’re met, all is good.

The little code that exists that receives MC/DC testing might be worth to be called "engineered".

I'm not even sure I exist.

“a person who designs, builds, or maintains engines, machines, or public works.”

Generally, a licensed PE is required to complete a four-year degree, and four years of engineering experience, after which rigorous testing confirms their qualification. This ensures a fundamental body of knowledge, in addition to the wisdom and experience of practicing under other experienced professionals. The Professional Engineer takes on a legal responsibility for their work, in part because they are trusted to ensure the welfare and safety of people and property.

Based on my 18 year career, I've only met a few SWEs that I would consider having both the requisite body of knowledge and experience to be called a Professional Software Engineer. Most of the SWEs I have met have lacked some fundamental knowledge that is required to complete a Software project to a high standard of quality and reliability. Even if you exclude networking hardware/software, computer architecture, systems engineering, embedded system design, and other niches (which aren't that difficult to learn, but anyway), most SWEs I've met over my career lack basic knowledge about software engineering.

Often, they simply don't have the experience of working in professional organizations. This is not taught to them in school, and you often have to work at a specific kind of place to learn these standards and processes on the job. But these standard and processes are necessary to coordinate work amongst teams in such a way to avoid common problems, such as lack of documentation, incorrect assumptions about how something works, delivering the wrong solution at the wrong time, etc.

Another thing that's become extremely common in the past few years is lacking a basic body of knowledge about software design. The history of software, its uses, algorithms, techniques, standards and protocols. This fundamental lack of knowledge leads to making mistakes that the industry learned to avoid decades ago.

Most SWEs I've met today are working off a body of knowledge from the 1990s or early 2000s. They have not learned modern software design or implementation techniques, outside of whatever is specific to one or two programming languages (and even then, their knowledge of the language is inconsistent). In addition, most of them have not taken training to teach them how to manage their work within a team effectively, which is especially important with the rise of Agile and Scrum.

It seems that most of what the average SWS knows today was learned from random blog posts submitted to tech forums, which were written by laymen, submitted by laymen, upvoted by laymen, and commented on by laymen. It's the blind leading the blind. And those blind people then go on to work for companies where they hire the blind.

I believe that the Software Engineering industry is almost entirely made up of people who don't understand their own ignorance, bluster their way through jobs and projects, and move from one company to the next, rarely ever significantly improving themselves, mostly leaving companies with shoddy work.

I know this isn't everyone's experience. But I have worked at enough places in enough different industries that it cannot be pure coincidence. HN is a good example: many of the comments on technical articles are often clearly from ignorant and inexperienced people who pass their assumptions off as fact. I can't count the number of blog posts upvoted here whose entire premise was fundamentally incorrect, yet a whole chorus of people chime in to agree, not really knowing what they're saying.

The point of the study, experience, and testing of engineering is to ensure that the people who claim they're engineers, actually can walk the walk, because in Professional Engineering, the result matters, and there are real world consequences.

SWEs are lucky that most of the projects they work on don't have as dire consequences as Professional Engineers. But the more software takes over the world, the greater their impact on society is. Software has lots of real world impacts - from charging electric cars, to suggesting when someone's gait might make them a criminal, to preventing someone from getting credit to buy a house, to creating addictive habits for young impressionable minds, and more. If the world cares about the impact of software, then it needs to hold digital engineers to a higher standard, the same way it did to physical engineers over a century ago.

[1] https://en.wikipedia.org/w/index.php?title=Professional_engi...

Software development is alchemy. Just like alchemy, software dev is not standardized, everyone has their own idiosyncratic naming systems, classifications and rules-of-thumb. Like alchemists, software engineers are often jealous of their proprietary knowledge. Just like alchemists, they are admired, feared and loathed for having secret knowledge. And just like alchemists, you have to be exceedingly brilliant to work in such a chaotic field and get anything done.

So, what changed alchemy into chemistry, and what will be the analog to that in software? Arguably the change started with notion of conservation of mass and energy, and the development of the periodic table (thanks to Lavoisier and Mendeleev, respectively). As for what that analog is for software, first we need a characterization of the field. With alchemy and chemistry both, it's essentially mixing stuff together, heating and cooling it, and seeing what happens. But what is it for software?

First, software engineering is not computer science. Computer science is a tiny subset of software engineering. In daily practice, almost all of computer science is encapsulated in a few, tiny standard libraries - the places where bubble-sorts and hash maps live. (This mistake is consistent, and leads to "leet code" style interview questions which are irrelevant to actual work).

I'd characterize software engineering as the set of solutions to a boundary value problem[0] described as "a set of interacting screens with behaviors pleasing to humans". The current solutions to this problem have been idiosyncratically defined by resource constraints that relaxed exponentially over time[1], and characterized by elements discovered at random, by necessity: e.g. kernels, processes, files, procedures, terminals, etc. In this analysis "language" functions as a kind of "coordinate system" as in physics[2][3], within which each of these elements are described, and within which elements are combined to make new elements, which eventually yield a solution to the boundary problem (which is termed "application"). There is some coorespondence with chemistry, in that we have "elements" which combine into higher-level structures, but we lack an analogy to "conservation of mass and energy". And our elements are still highly partitioned according to coordinate system (although there have been several[4] heroic[5] attempts to unify them within a single framework.)

I don't particularly know what the standardization of software alchemy into software engineering will look like, but I'm certain that this analysis, or something similar to it, is the first steps in the right direction. Personally, I look forward to the day we can shed the considerable weight of our alchemical origins!

0 - https://en.wikipedia.org/wiki/Boundary_value_problem

1 - https://en.wikipedia.org/wiki/Moore's_law

2 - https://en.wikipedia.org/wiki/Coordinate_system

3 - https://www.rosettacode.org/wiki/Rosetta_Code - the same problem is solved in many languages. For applications: https://todomvc.com/

4 - https://en.wikipedia.org/wiki/Lambda_calculus

5 - https://en.wikipedia.org/wiki/Turing_machine