6 ms·

Is Software Engineering Real Engineering?

59 points by signa11 3y ago

giraffe_lady 3y ago
I love this series, I learned a lot from it and think about it often. It changed my mind on this subject completely.
jillesvangurp 3y ago
There are a couple of fun arguments here: - 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.
- 303uru 3y ago
  >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 Which is hilarious, because nothing in the real world works that way. My BIL is a civil engineer and he spends tons of time traveling to sites to solve problems that pop up during implementation.
  - Anechoic 3y ago
    Exactly, which is why "as-builts" are a thing.
  - nottheengineer 3y ago
    So are implementation problems of civil engineering the equivalent of prod problems in software engineering?
systems 3y ago
well engineering is not project management , while engineers do a lot of project management, PM is not engineering 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
blastonico 3y ago
Real engineers drive trains and we don't do that. So we're not real engineers. :-)
- zeroonetwothree 3y ago
  I would say it’s the train drivers that deviated from the original meaning (Latin: ingeniare, “to contrive or devise”)
_fat_santa 3y ago
In many ways SWE is like real engineering but with some major differences. I could use the classic example "we aren't building bridges" but that's too simplistic. I think the biggest difference between us and the rest of engineering is the "method of delivery" and how that affects the other processes. 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.
- AndrewKemendo 3y ago
  Isn't every company doing all they can to force their other engineering into software delivery paradigm? The whole "seat warmers as a service" pops to mind That's the whole idea of "Digital Engineering" The former Acquisitions Chief for the US Air Force just announced that they got a contract to CERTIFY a plane for airworthiness before ever actually building one in real life [1]. So yeah, it's happening [1]https://www.istaridigital.com/press-releases/air-force-awards-istari-digital-19m-contract-to-develop-worlds-first-digitally-certified-airplane https://www.istaridigital.com/press-releases/air-force-award...
- mikecx 3y ago
  As a counter to your first example, I once had software deployed in some U.S. embassies in some not so great parts of the world. The machines the software lived on were air-gapped and on computers built specifically not to allow external connections (different keyboard/mouse connectors, no USB, no CD). To deploy an update required a human, some long flights, and replacement parts. While it's not common, I think it would still break that definition of what is/isn't an engineer. For me, it comes down to the level of rigor required. I think developing avionics software is probably engineering whereas building an phone app to view/share pictures of cats likely isn't.
Finster 3y ago
I didn't realize it was time to drag this old chestnut out of storage. Nothing like dusting off a decades long flame war. I'm sure everyone will come to an agreement this time.
nercury 3y ago
It's mostly fashion.
jehb 3y ago
Software engineering is what it is. 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.
deleted 3y ago
[deleted]
freitzkriesler2 3y ago
Funny post. I came from purely webdev software engineering to hardware engineering and let me tell you, it is an interesting coalescence of mechanical, electrical, and software engineering (both firmware and regular 'ol software). 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.
- tamimio 3y ago
  > 'd say it goes mechanical, software, electrical, and then firmware. I think it’s about the mindset, like how some people enjoy doing numbers while others see it gibberish, personally I find embedded easier to work with, on the other hand, I still can’t fully comprehend React spaghetti.
avgcorrection 3y ago
Is this debate based in pragmatic concerns or just Real Engineering-envy?
abcrawf 3y ago
Of course it is; almost by definition. The confusion stems from the fact that most people use the term when they actually mean plumbing.
simpaticoder 3y ago
The problem with this question is that, if it's not engineering, what is it? A better question is motivated by studying the history of chemistry and its progenitor, alchemy. That is: is software development alchemy or chemistry? 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 https://en.wikipedia.org/wiki/Boundary_value_problem 1 - https://en.wikipedia.org/wiki/Moore's_law https://en.wikipedia.org/wiki/Moore's_law 2 - https://en.wikipedia.org/wiki/Coordinate_system https://en.wikipedia.org/wiki/Coordinate_system 3 - https://www.rosettacode.org/wiki/Rosetta_Code https://www.rosettacode.org/wiki/Rosetta_Code - the same problem is solved in many languages. For applications: https://todomvc.com/ https://todomvc.com/ 4 - https://en.wikipedia.org/wiki/Lambda_calculus https://en.wikipedia.org/wiki/Lambda_calculus 5 - https://en.wikipedia.org/wiki/Turing_machine https://en.wikipedia.org/wiki/Turing_machine
jerf 3y ago
Engineering, no matter where it is, is about reacting to costs and benefits. Software engineering has radically different costs and benefits than physical engineering. It would be inappropriate to blindly copy over the engineering practices from other fields without adapting to the huge changes on both the costs and benefits sides. 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.
- aswanson 3y ago
  In electrical engineering, there is some iteration in development (board spins). But nowhere near the flexibility of software. That's why it's almost always better, imo, to turn a hardware problem into a software one.
  - gavinhoward 3y ago
    The Therac-25 disagrees with you. Hardware interlocks were replaced with software. And people died.
Antoniocl 3y ago
I would say it depends on the specific role and project, but for most people who write code, likely not. 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
- whatever1 3y ago
  Not a CE myself, but computer engineers definitely consider physics in their solutions since they have to consider complexity, computational speed, memory restrictions, concurrency etc Aka they take fundamental theoretical concepts and given the physical constraints we have from the existing computing systems they come up with viable solutions.
  - Antoniocl 3y ago
    I agree that the work that CEs do in the vein of what you're describing is closer to my conception of engineering. I also don't think most people who call themselves a "software engineer" fit that description though. My guess would be less than 10%?
- PartiallyTyped 3y ago
  You could consider it as applied science in that we are dealing with CPUs, we do benchmarks, we build models of things ... but this isn't work that everyone does. I wouldn't call most SWE work close to applied math or logic. Very few people get to deal with things that are math-adjacent or do applied math in general. Many things are just .. plumbing data.
  - Antoniocl 3y ago
devmor 3y ago
There are times that I feel like I’m doing engineering when I write software. Those are often the most fulfilling (and most frustrating) parts of my job. But most of the time what I’m doing is just putting things together or repairing things to achieve a goal - not figuring out anything new. I’d say I feel more like a construction worker for 80-90% of my workload.
nodra 3y ago
First time I ever looked up the definition of an engineer: “a person who designs, builds, or maintains engines, machines, or public works.”
agloe_dreams 3y ago
One of my favorite arguments in this topic is when 'Real Engineers' say "If my part fails, someone could DIE!"...to the Facebook/IG/TicTok Engineer whose role in Social media drives suicides across the world.
deleted 3y ago
[deleted]
Workaccount2 3y ago
Electrical Engineer who can write messy but functional code in C and Python, but mainly deals with analog circuits at work. 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.
- amelius 3y ago
  Yeah, either way we're pushed to the limits of thinking. If we weren't then that means we could make greater things, ergo, we're pushed to our limits.
- foooorsyth 3y ago
  Good distillation of the difference between working with atoms vs. bits.
- bbor 3y ago
  I think computer scientists work in a “parallel universe of perfect logic” but sadly I strongly disagree that the vast majority of software engineers get that privilege. IMO, contemporary SWE involves a lot of black box treatment, learning complex systems on the fly, and untested large code bases. All of that leads to similar dynamics as more direct physical dynamics in other engineering disciplines do: unexplained behavior, doing things by spec, debugging by process of elimination, etc. And that’s before mentioning the direct problem of device and network issues; I understand this to be a certainty for those doing things on a global scale.
mikewarot 3y ago
If it were real engineering, we would be able to safely run arbitrary code, just like you can safely plug anything into an outlet and not take down the grid.
- zeroonetwothree 3y ago
  There are some safeties built in (fuses/circuit breakers) but ultimately it’s not so different than safeguards in software. Hence why the electric grid often has issues.
hermannj314 3y ago
There is a big difference between the person that builds the skyscraper and the person that does the maintenance. 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.
swader999 3y ago
Only if they take liability for their work. I would never want to work that way in a business system. Space shuttle, sure.
stronglikedan 3y ago
All engineering is making something complex and functional, so yes, absolutely. Of course, there is software that is neither of these things, but there's also fallen trees across rivers that serve as bridges and eventually erode.
baxuz 3y ago
Depends. 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.
- zeroonetwothree 3y ago
  Who made you the Grand High Arbiter of language use?
- velcrovan 3y ago
  I think it’s worth separating the question of “do software engineers actually carry professional liability or have their designs independently reviewed” from the question of “is software development work sufficiently consequential and verifiable to warrant professional liability and certification requirements?" To me, the answer to the first is obviously no and the second is obviously yes.
- agloe_dreams 3y ago
  I think that is an argument for the term rather than against. A SWE SHOULD be held responsible for the things they make and the impacts it causes. Additionally, so should PMs and CEOs but heyyyy. I guess the big issue is that it is easy to place blame in the case of a bridge failing...but much harder when a system products mass suicides.
- funnyflywheel 3y ago
  Apparently, the National Council of Examiners for Engineering and Surveying (the board that regulates other engineering fields in the USA, such as civil engineering) used to offer a Professional Engineer (PE) exam for software engineering, but it was dropped in 2019 due to lack of participation and bad prospects for increased participation. https://ncees.org/ncees-discontinuing-pe-software-engineering-exam/ https://ncees.org/ncees-discontinuing-pe-software-engineerin...
deleted 3y ago
[deleted]
thrwy_918 3y ago
if you don't have to have any qualifications, certifications or licenses to practice it, it's not real engineering
- stratigos 3y ago
  I agree, which is why Ive designed my own set of qualifications for a web developer to be considered senior, and they have integrity and can be reduced to scalar values if needed. Thousands of interviews have proven these qualifications to be successful at sourcing candidates that are true seniors and those that are not. Most businesses dont need to care since they can find successful outcomes either way. That doesnt mean that qualifications (which can be turned into certifications just by having a recognizable name attached to one's firm) do not exist, that just means software is truly soft in that the consequences of being under-qualified are not at all as drastic as the consequences of being under-qualified to fix powerlines or design a nuclear reactor.
trey-jones 3y ago
My take on this which inevitably steps on toes in these parts: 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.
2OEH8eoCRo0 3y ago
Almost nobody uses science and mathematics to prove a design before coding. The closest I came was the glacial waterfall environment of defense software that I now realize wasn't so bad.
- zeroonetwothree 3y ago
  Who is writing a mathematical proof of their bridge design?
  - 2OEH8eoCRo0 3y ago
    Didn't say it needed to be a purely mathematical proof. They don't accomplish this with a combination of materials science and CAD software with a patchwork of regulation/review?
lr4444lr 3y ago
I've thought about this a lot as a dev. IMHO, no, and the main reason is a strong resistance to standardization: in OS platforms that we work on, software libraries to do basic things that we include, education credentials, and QA. We simply can't agree on a practical knowledge base as a profession that beyond the 1st and 2nd year CS fundamentals. There are some best practices that we've seem to coalesce around, but even those are somewhat ill-defined. 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.
stratigos 3y ago
The main difference is that software engineering is extremely tolerant of poor engineering standards and practices, relative to "traditional" engineering disciplines. 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.
jesse__ 3y ago
Hot take alert: 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.
- Traubenfuchs 3y ago
  I'd like to say I fully agree with you, but I don't think this "perfection" you talk about is usually reached, not even in your exceptional domain: Remember the living lists of CPU errata! And retpoline, meltdown, spectre! God only knows how many of those are out there, unknown or actively exploited.
  - jesse__ 3y ago
    It's true I was in a bit of a dramatic mood, but there really is truth in that statement; at tape-out (release), 0 known-bugs will exist. That's not to say 0 total bugs exist which, as you correctly point out, is obviously and demonstrably not true, but to the best knowledge of people working on the product at the time, it works perfectly.
Traubenfuchs 3y ago
No, it's mostly a highly subjective and opinion driven craft. One just can not call CRUD spaghetti and SPA madness engineering. The little code that exists that receives MC/DC testing might be worth to be called "engineered".
- tamimio 3y ago
  Pretty much yeah, it isn’t a software engineering issue, it’s the majority of what’s built wouldn’t count as engineering.
kingkongjaffa 3y ago
My previous career was mechanical engineering. I was on track to be a licensed engineer in my country, I have a mechE masters degree. 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.
steve_adams_86 3y ago
When I wrote strictly software on computers, typically with a way to push fixes, I felt like it wasn’t really “real” engineering. 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.
zeroonetwothree 3y ago
We have so many bad cases of people mislabelling themselves like chiropractors that call themselves doctors. This doesn’t seem like the biggest “problem” to worry about. Next you’ll be complaining about people who call themselves “sanitation engineers”. I think you can call a job whatever you want as long as it’s not deceptive. Any current conventions are arbitrary anyway and have nothing to do with the original meaning of the word “engineer”. And millions of people already use “software engineer” so it’s a well established term.
0xbadcafebee 3y ago
We may be "small-e" engineers, but we aren't Professional Engineers[1]. That requires a license, a degree, training, and an organization that spells out what a discipline is competent at doing. 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_engineer https://en.wikipedia.org/w/index.php?title=Professional_engi...
wendyshu 3y ago
"When a debate descends to talking about the meanings of words, it's irrecoverable." -- Paul Graham
esics6A 3y ago
No it's not real engineering at all but a different thing altogether. Engineering is the application of hard sciences like chemistry, physics and biology to solve real world problems. Software development can be part of what an engineer does to solve that problem but it's not engineering in itself. Software "engineering" is actually applied mathematics particularly logic to program a computer to complete tasks organized as algorithms. This is why some algorithms and functions in software can be proved via mathematical proofs.
sprior 3y ago
I build ephemeral data structures inside virtual environments that run in a container in a virtual machine using virtual memory on a processor implemented in microcode. I'm not even sure I exist.
OnlyMortal 3y ago
I don’t tend to think so, as a general rule. 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.
deleted 3y ago
[deleted]
Veserv 3y ago
Most software development is not engineering. Engineering is about requirements, guarantees, and specifications. 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.
tamimio 3y ago
The problem is not if software engineers are engineers or not, the problem is with defining software itself, as an EE myself, I do software, we learned how to write programs even in assembly back in the school too, however, you have now (at that’s even before the AI LLM hype) a horde of people who call themselves “engineers” after attending a 3 weeks bootcamp in some front-end framework or library or some data analysis course, they will know how to import a library and repeat some known processes, they lack what every engineer should know, architecture design, I personally believe that if someone can convert an abstract idea into an applicable design, is in fact an engineer, software or not.
osigurdson 3y ago
I think it is best to drop all analogies to other disciplines (“it’s like a bridge but…”, “it’s like building a house but…”). 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?

59 points by signa11 3y ago

I love this series, I learned a lot from it and think about it often. It changed my mind on this subject completely.

There are a couple of fun arguments here: - 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.

303uru 3y ago
>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 Which is hilarious, because nothing in the real world works that way. My BIL is a civil engineer and he spends tons of time traveling to sites to solve problems that pop up during implementation.
- Anechoic 3y ago
  Exactly, which is why "as-builts" are a thing.
- nottheengineer 3y ago
  So are implementation problems of civil engineering the equivalent of prod problems in software engineering?

systems 3y ago

well engineering is not project management , while engineers do a lot of project management, PM is not engineering 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

blastonico 3y ago

Real engineers drive trains and we don't do that. So we're not real engineers. :-)

zeroonetwothree 3y ago
I would say it’s the train drivers that deviated from the original meaning (Latin: ingeniare, “to contrive or devise”)

_fat_santa 3y ago

In many ways SWE is like real engineering but with some major differences. I could use the classic example "we aren't building bridges" but that's too simplistic. I think the biggest difference between us and the rest of engineering is the "method of delivery" and how that affects the other processes. 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.

AndrewKemendo 3y ago
Isn't every company doing all they can to force their other engineering into software delivery paradigm? The whole "seat warmers as a service" pops to mind That's the whole idea of "Digital Engineering" The former Acquisitions Chief for the US Air Force just announced that they got a contract to CERTIFY a plane for airworthiness before ever actually building one in real life [1]. So yeah, it's happening [1]https://www.istaridigital.com/press-releases/air-force-awards-istari-digital-19m-contract-to-develop-worlds-first-digitally-certified-airplane https://www.istaridigital.com/press-releases/air-force-award...
mikecx 3y ago
As a counter to your first example, I once had software deployed in some U.S. embassies in some not so great parts of the world. The machines the software lived on were air-gapped and on computers built specifically not to allow external connections (different keyboard/mouse connectors, no USB, no CD). To deploy an update required a human, some long flights, and replacement parts. While it's not common, I think it would still break that definition of what is/isn't an engineer. For me, it comes down to the level of rigor required. I think developing avionics software is probably engineering whereas building an phone app to view/share pictures of cats likely isn't.

Finster 3y ago

I didn't realize it was time to drag this old chestnut out of storage. Nothing like dusting off a decades long flame war. I'm sure everyone will come to an agreement this time.

nercury 3y ago

It's mostly fashion.

jehb 3y ago

Software engineering is what it is. 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.

deleted 3y ago

[deleted]

freitzkriesler2 3y ago

Funny post. I came from purely webdev software engineering to hardware engineering and let me tell you, it is an interesting coalescence of mechanical, electrical, and software engineering (both firmware and regular 'ol software). 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.

tamimio 3y ago
> 'd say it goes mechanical, software, electrical, and then firmware. I think it’s about the mindset, like how some people enjoy doing numbers while others see it gibberish, personally I find embedded easier to work with, on the other hand, I still can’t fully comprehend React spaghetti.

avgcorrection 3y ago

Is this debate based in pragmatic concerns or just Real Engineering-envy?

abcrawf 3y ago

Of course it is; almost by definition. The confusion stems from the fact that most people use the term when they actually mean plumbing.

simpaticoder 3y ago

The problem with this question is that, if it's not engineering, what is it? A better question is motivated by studying the history of chemistry and its progenitor, alchemy. That is: is software development alchemy or chemistry? 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 https://en.wikipedia.org/wiki/Boundary_value_problem 1 - https://en.wikipedia.org/wiki/Moore's_law https://en.wikipedia.org/wiki/Moore's_law 2 - https://en.wikipedia.org/wiki/Coordinate_system https://en.wikipedia.org/wiki/Coordinate_system 3 - https://www.rosettacode.org/wiki/Rosetta_Code https://www.rosettacode.org/wiki/Rosetta_Code - the same problem is solved in many languages. For applications: https://todomvc.com/ https://todomvc.com/ 4 - https://en.wikipedia.org/wiki/Lambda_calculus https://en.wikipedia.org/wiki/Lambda_calculus 5 - https://en.wikipedia.org/wiki/Turing_machine https://en.wikipedia.org/wiki/Turing_machine

jerf 3y ago

Engineering, no matter where it is, is about reacting to costs and benefits. Software engineering has radically different costs and benefits than physical engineering. It would be inappropriate to blindly copy over the engineering practices from other fields without adapting to the huge changes on both the costs and benefits sides. 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.

aswanson 3y ago
In electrical engineering, there is some iteration in development (board spins). But nowhere near the flexibility of software. That's why it's almost always better, imo, to turn a hardware problem into a software one.
- gavinhoward 3y ago
  The Therac-25 disagrees with you. Hardware interlocks were replaced with software. And people died.

Antoniocl 3y ago

I would say it depends on the specific role and project, but for most people who write code, likely not. 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

whatever1 3y ago
Not a CE myself, but computer engineers definitely consider physics in their solutions since they have to consider complexity, computational speed, memory restrictions, concurrency etc Aka they take fundamental theoretical concepts and given the physical constraints we have from the existing computing systems they come up with viable solutions.
- Antoniocl 3y ago
  I agree that the work that CEs do in the vein of what you're describing is closer to my conception of engineering. I also don't think most people who call themselves a "software engineer" fit that description though. My guess would be less than 10%?
PartiallyTyped 3y ago
You could consider it as applied science in that we are dealing with CPUs, we do benchmarks, we build models of things ... but this isn't work that everyone does. I wouldn't call most SWE work close to applied math or logic. Very few people get to deal with things that are math-adjacent or do applied math in general. Many things are just .. plumbing data.
- Antoniocl 3y ago

devmor 3y ago

There are times that I feel like I’m doing engineering when I write software. Those are often the most fulfilling (and most frustrating) parts of my job. But most of the time what I’m doing is just putting things together or repairing things to achieve a goal - not figuring out anything new. I’d say I feel more like a construction worker for 80-90% of my workload.

nodra 3y ago

First time I ever looked up the definition of an engineer: “a person who designs, builds, or maintains engines, machines, or public works.”

agloe_dreams 3y ago

One of my favorite arguments in this topic is when 'Real Engineers' say "If my part fails, someone could DIE!"...to the Facebook/IG/TicTok Engineer whose role in Social media drives suicides across the world.

deleted 3y ago

[deleted]

Workaccount2 3y ago

Electrical Engineer who can write messy but functional code in C and Python, but mainly deals with analog circuits at work. 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.

amelius 3y ago
Yeah, either way we're pushed to the limits of thinking. If we weren't then that means we could make greater things, ergo, we're pushed to our limits.
foooorsyth 3y ago
Good distillation of the difference between working with atoms vs. bits.
bbor 3y ago
I think computer scientists work in a “parallel universe of perfect logic” but sadly I strongly disagree that the vast majority of software engineers get that privilege. IMO, contemporary SWE involves a lot of black box treatment, learning complex systems on the fly, and untested large code bases. All of that leads to similar dynamics as more direct physical dynamics in other engineering disciplines do: unexplained behavior, doing things by spec, debugging by process of elimination, etc. And that’s before mentioning the direct problem of device and network issues; I understand this to be a certainty for those doing things on a global scale.

mikewarot 3y ago

If it were real engineering, we would be able to safely run arbitrary code, just like you can safely plug anything into an outlet and not take down the grid.

zeroonetwothree 3y ago
There are some safeties built in (fuses/circuit breakers) but ultimately it’s not so different than safeguards in software. Hence why the electric grid often has issues.

hermannj314 3y ago

There is a big difference between the person that builds the skyscraper and the person that does the maintenance. 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.

swader999 3y ago

Only if they take liability for their work. I would never want to work that way in a business system. Space shuttle, sure.

stronglikedan 3y ago

All engineering is making something complex and functional, so yes, absolutely. Of course, there is software that is neither of these things, but there's also fallen trees across rivers that serve as bridges and eventually erode.

baxuz 3y ago

Depends. 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.

zeroonetwothree 3y ago
Who made you the Grand High Arbiter of language use?
velcrovan 3y ago
I think it’s worth separating the question of “do software engineers actually carry professional liability or have their designs independently reviewed” from the question of “is software development work sufficiently consequential and verifiable to warrant professional liability and certification requirements?" To me, the answer to the first is obviously no and the second is obviously yes.
agloe_dreams 3y ago
I think that is an argument for the term rather than against. A SWE SHOULD be held responsible for the things they make and the impacts it causes. Additionally, so should PMs and CEOs but heyyyy. I guess the big issue is that it is easy to place blame in the case of a bridge failing...but much harder when a system products mass suicides.
funnyflywheel 3y ago
Apparently, the National Council of Examiners for Engineering and Surveying (the board that regulates other engineering fields in the USA, such as civil engineering) used to offer a Professional Engineer (PE) exam for software engineering, but it was dropped in 2019 due to lack of participation and bad prospects for increased participation. https://ncees.org/ncees-discontinuing-pe-software-engineering-exam/ https://ncees.org/ncees-discontinuing-pe-software-engineerin...

deleted 3y ago

[deleted]

thrwy_918 3y ago

if you don't have to have any qualifications, certifications or licenses to practice it, it's not real engineering

stratigos 3y ago
I agree, which is why Ive designed my own set of qualifications for a web developer to be considered senior, and they have integrity and can be reduced to scalar values if needed. Thousands of interviews have proven these qualifications to be successful at sourcing candidates that are true seniors and those that are not. Most businesses dont need to care since they can find successful outcomes either way. That doesnt mean that qualifications (which can be turned into certifications just by having a recognizable name attached to one's firm) do not exist, that just means software is truly soft in that the consequences of being under-qualified are not at all as drastic as the consequences of being under-qualified to fix powerlines or design a nuclear reactor.

trey-jones 3y ago

My take on this which inevitably steps on toes in these parts: 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.

2OEH8eoCRo0 3y ago

Almost nobody uses science and mathematics to prove a design before coding. The closest I came was the glacial waterfall environment of defense software that I now realize wasn't so bad.

zeroonetwothree 3y ago
Who is writing a mathematical proof of their bridge design?
- 2OEH8eoCRo0 3y ago
  Didn't say it needed to be a purely mathematical proof. They don't accomplish this with a combination of materials science and CAD software with a patchwork of regulation/review?

lr4444lr 3y ago

I've thought about this a lot as a dev. IMHO, no, and the main reason is a strong resistance to standardization: in OS platforms that we work on, software libraries to do basic things that we include, education credentials, and QA. We simply can't agree on a practical knowledge base as a profession that beyond the 1st and 2nd year CS fundamentals. There are some best practices that we've seem to coalesce around, but even those are somewhat ill-defined. 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.

stratigos 3y ago

The main difference is that software engineering is extremely tolerant of poor engineering standards and practices, relative to "traditional" engineering disciplines. 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.

jesse__ 3y ago

Hot take alert: 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.

Traubenfuchs 3y ago
I'd like to say I fully agree with you, but I don't think this "perfection" you talk about is usually reached, not even in your exceptional domain: Remember the living lists of CPU errata! And retpoline, meltdown, spectre! God only knows how many of those are out there, unknown or actively exploited.
- jesse__ 3y ago
  It's true I was in a bit of a dramatic mood, but there really is truth in that statement; at tape-out (release), 0 known-bugs will exist. That's not to say 0 total bugs exist which, as you correctly point out, is obviously and demonstrably not true, but to the best knowledge of people working on the product at the time, it works perfectly.

Traubenfuchs 3y ago

No, it's mostly a highly subjective and opinion driven craft. One just can not call CRUD spaghetti and SPA madness engineering. The little code that exists that receives MC/DC testing might be worth to be called "engineered".

tamimio 3y ago
Pretty much yeah, it isn’t a software engineering issue, it’s the majority of what’s built wouldn’t count as engineering.

kingkongjaffa 3y ago

My previous career was mechanical engineering. I was on track to be a licensed engineer in my country, I have a mechE masters degree. 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.

steve_adams_86 3y ago

When I wrote strictly software on computers, typically with a way to push fixes, I felt like it wasn’t really “real” engineering. 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.

zeroonetwothree 3y ago

We have so many bad cases of people mislabelling themselves like chiropractors that call themselves doctors. This doesn’t seem like the biggest “problem” to worry about. Next you’ll be complaining about people who call themselves “sanitation engineers”. I think you can call a job whatever you want as long as it’s not deceptive. Any current conventions are arbitrary anyway and have nothing to do with the original meaning of the word “engineer”. And millions of people already use “software engineer” so it’s a well established term.

0xbadcafebee 3y ago

We may be "small-e" engineers, but we aren't Professional Engineers[1]. That requires a license, a degree, training, and an organization that spells out what a discipline is competent at doing. 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_engineer https://en.wikipedia.org/w/index.php?title=Professional_engi...

wendyshu 3y ago

"When a debate descends to talking about the meanings of words, it's irrecoverable." -- Paul Graham

esics6A 3y ago

No it's not real engineering at all but a different thing altogether. Engineering is the application of hard sciences like chemistry, physics and biology to solve real world problems. Software development can be part of what an engineer does to solve that problem but it's not engineering in itself. Software "engineering" is actually applied mathematics particularly logic to program a computer to complete tasks organized as algorithms. This is why some algorithms and functions in software can be proved via mathematical proofs.

sprior 3y ago

I build ephemeral data structures inside virtual environments that run in a container in a virtual machine using virtual memory on a processor implemented in microcode. I'm not even sure I exist.

OnlyMortal 3y ago

I don’t tend to think so, as a general rule. 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.

deleted 3y ago

[deleted]

Veserv 3y ago

Most software development is not engineering. Engineering is about requirements, guarantees, and specifications. 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.

tamimio 3y ago

The problem is not if software engineers are engineers or not, the problem is with defining software itself, as an EE myself, I do software, we learned how to write programs even in assembly back in the school too, however, you have now (at that’s even before the AI LLM hype) a horde of people who call themselves “engineers” after attending a 3 weeks bootcamp in some front-end framework or library or some data analysis course, they will know how to import a library and repeat some known processes, they lack what every engineer should know, architecture design, I personally believe that if someone can convert an abstract idea into an applicable design, is in fact an engineer, software or not.

osigurdson 3y ago

I think it is best to drop all analogies to other disciplines (“it’s like a bridge but…”, “it’s like building a house but…”). 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?