Software is neither engineering nor science, so the terms Software Engineering and Computer Science are mislabels at best and extinction propaganda at worst.
For example, a mechanical engineer is someone that designs mechanical systems. In order to do that, they will need specialized and very expensive equipment, and the end result will be produced with machines costing hundreds of thousands or even millions of dollars. Designing a system and producing a single one-off artifact are two very different things, and that's why a lone craftsman in their shed cannot do actual engineering (outside of pen and paper mockups).
With software, otoh, it takes nothing to go from default nginx for serving your static personal website to an orchestrated cluster of containers and load balancers. The problem is that, for the latter, if you haven't got an engineer-like training, you will not be able to reason about the system, because you didn't really design it.
Not really. The difficulty to manufacture something isn't tied to the ability to engineer it. In fact, good engineers try to make the item easier/cheaper to manufacture. Take the AK-47 vs the M-16 - one used more exotic (for the time) materials with a more expensive and involved production process. The other was made with looser tolerances out of cheap stamped steel and wood that could be cranked out quickly. Yet they were both (eventually) of similar effectiveness.
These days, we have CAD and 3D printing available to craftsmen. If you want to build it out of metal and make it reproducible, you can build and print the parts to create molds to cast them from. Same thing for people how have a lathe and/or milling machine. In some cases you can get them used for a few hundred dollars. Record your dimensions and process and you can crank out copies of items with great results - no engineering training needed.
It's like a lot of these custom car/motorcycle builders vs actual engineers designing for a major manufacturer. You are both building a product but one places a lot more rigor on the science, data, and testing behind the decisions. That doesn’t mean the custom builders don't build good stuff, just that you won't get answers to things like how much force a particular part can take or how much energy it will absorb in a crash.
In software, you might have some people still doing real software engineering, but they are in sectors that take documentation and testing more seriously. Not that every player takes this dedicated approach, but potentially parts of auto, aviation and defense fall into this.
Other way around. The difference between engineering and building is that building refers to the building of a component in isolation, while engineering is about the building an entire system through the combination of multiple components. Most software — and all software that is actually used — is a built system.
> but one places a lot more rigor on the science
That'd be "professional engineering"; sometimes referred to as PE for short. We're talking about engineering (sans professional) here.
Hence why they are engineered. I suspect you mentioned houses because the people who build houses are often referred to as builders, but that is because the people working houses often only do work on a single component. The system as a whole is referred to as engineering, though.
> with calculations and formalised decision-making processes and the like.
You too seem to be confusing "engineering" with "professional engineering". While societies of professional engineers would like people to think that engineering is defined by mathematical and scientific rigour, that's not how anyone actually uses the term in practice. The "software engineering" label wouldn't exist if they did.
The word "patterns" a la software patterns was taken directly from the writings of an architect of physical buildings (namely Christopher Alexander). It is not an accident that it was not taken from the work of a construction worker, not even a high-level one in charge of hiring subcontractors and of years-long billion-dollar construction projects.
The most salient difference between blueprints and software artifacts is the sheer complexity of software artifacts these days (which is why there aren't organizations that employ many tens of thousands of draftsmen and architects of physical structures) but that is a difference in degree, not a difference in kind.
There is engineering as a discipline (e.g., mechanical, electrical, industrial, civil, aerospace...etc.) and engineering in a more colloquial sense like "I did some hillbilly engineering and rigged up a pea sheller". Both involve solving problems.
The former typically involves the person going through a rigorous 4-5 year program where they take a bunch of advanced math and physics classes and a ton of other classes (including coding and robotics as well as more specific classes such as power electronics) that teach logical thinking and problem solving. I'm always amazed that I can more or less talk to any engineer across the country (different state, different university, different engineering discipline) and still recognize their training and that hyper analytical mindset and feel the kinship. That of course doesn't mean that there aren't similar analytical people that went in other directions, but the training is a real thing.
A professional engineer passed their fundamentals of engineering exam, got their degree, and then took their professional engineering exam. You used to have to get 4 years of work experience before applying, but I think they got rid of that. It's an awful 8-hour exam with a pretty low pass rate. Honestly though, the PE usually just means the engineer was willing to spend 3-6 months prepping for the exam and has a need for the license to stamp papers. A lot of engineers never get it if they don't need it. I believe you need it in some cases for court cases.
As far as software engineering goes. It seems to be a discipline that matches the second colloquial definition more in a lot of cases. In some cases they have actual software engineering degrees where the student takes all the standard intro engineering courses (calculus, linear algebra, statistics, differential equations, statics, dynamics, circuits, thermodynamics) before doing the core classes distinct to that major. In that case, I'd call them an engineer due to the training and think it's an appropriate job title even if they get a job slinging corporate java, which would not typically be viewed as traditional engineering. So they're an engineer...not necessarily doing engineering. Does that really make sense? My own definition breaks down if we apply this to the same engineer becoming a garbage man. They're still an engineer by training, but they're most definitely not doing engineering anymore.
Also, if Pete gets a job slinging code out of highschool...we can say he's doing engineering in the colloquial second sense, but is he an engineer in the first sense? No.
Clear as mud? As an engineer I now must flog myself for my own internal inconsistencies. In all seriousness, language is hard and sometimes imprecise. I didn't realize my rambling got so long and apologize.
If you talk about editing the data structure, then it depends.
https://www.washington.edu/news/2020/03/02/not-a-math-person...
That's not to say it all needs to be written down; someone can do the "engineering" of a small project all in their own head and then implement it themselves.
The engineering process itself is a form of knowledge work. A single person can do both tasks of course.
But I also think that the software development process is maybe too flexible to be regulated, and tested like the other disciplines, a building is always a building, a material is always the same material.
But in software, who is going to test and verify the "materials" if they change constantly and evolve? It seems to me that any attempt at standardizing software development could slow down development so much that most won't find it to be worth it.
If you want to do anything outside of what's permitted by the book, that's generally when you call an engineer.
It does seem to me that a lot of calls for formalizing things in software is trying to skip over the engineering step and jump straight to a codebook that crystalizes the common engineered solutions into a list of dos and don'ts.
You have your "not an engineer" people who have built airplanes, cars, motorcycles and whatnot. They are good with their tools and they are able to make amazing things. Some of them might even be doing these things for a living.
Then you get your "real" engineers who need to measure and test and spec out and define limits and must be able to provably demonstrate that the bridge will not fall over.
In software you have your journeymen who build software for a living, they are good at what they do and they are building amazing things, and then you have your "engineers" who are building avionics for rockets and planes, the control software for nuclear reactors and so on. They need to prove their software works as intended and cannot venture beyond it's parameters etc.
Two very different professions, two very different types of people, yet both are (on the surface) doing something that appears very similar.
The problem is that running "studies" on what the author and others are asking for is effectively impossible. You can't get 25 teams of suitably-random professionals to build a non-trivial program one way, and 25 to build it another, and then do statistically-significant analysis of them, because that would be a staggeringly expensive study... and that is just for one such study, which would then be, you know, wrong, incorrectly analyzed, controversial, biased, etc. The expense of getting a representative set of such studies, independently conducted, enough to actually settle a question, beggars the imagination.
Even such studies as have been performed are almost all invalidated by virtue of being run on inexperienced students. I'm not really that interested in whether inexperienced students do or do not do well with some methodology for the most part. What happens with professionals?
In the meantime, all we've got is experiences. Contrary to popular belief, science does not mandate that we therefore curl up into a ball and cry ourselves to sleep at night. We just have to do our best. Berating other people for not pouring billions of dollars into the simplest of studies won't help much. They're still not going to, and you still have to go to work, sit down, and figure out how you're going to accomplish some task, even it you don't have double-blinded meta-analyses from decades of studies to pull from.
And to explore running studies a bit further. The second time you build a system goes so much better because you already know all of the weird edge cases. And the third better still because your failures in the second time has cured you of some of your hubris.
Even if you somehow bankrolled 50 repeat projects and did the statistics etc correctly, you're still going to get some weird artifacts because some of those teams have people who did the thing before. You'll learn the wrong lesson when the real lesson is "make sure Bob is working on Bluetooth because he's done it 10 times before."
Starting with people with no experience is likewise not interesting because nobody really cares what lessons you learn by turning a bunch of muggles loose on something difficult.
What you need to bankroll is 50 teams worth of people who spend their entire careers testing out a hypothesis. (And even then you probably need to somehow control their professional communities in some way because again who cares what some small group of people approaches a problem when you could instead have people who go out and learn things from other people.)
That is to say, as a programmer, I feel like we're wading in an ocean of unknown size and depth. As we learn, by trial and error, the confines of that space will fuel the standardization and codification of the craft will only increase as a function of time until it isn't craft, but applied science.
Edit: s/applied science/engineering/
Writing isn't an engineering discipline. And all industries rely heavily on writing. Could it be that writing software is just writing for computers and as such could only by codified within another engineering discipline and not by its own?
Then, you can make a product that was applied engineering, but you can't replace all the others that not.
Civil engineering and friends have the advantage that is built on top of the universe, that despite claims to the contrary, was not hacked with perl!
It's not a technical issue, it's a 'software doesn't really kill people so government doesn't intervene in it'. In the case where the software is life and death it's generally developed in ways similar to 'real' engineering
Fundamentally folks built building/structures without engineering, just so consistently caused death and destruction that govt stepped in and started requiring licensed trained folks, approval trails etc. without this real world intervention regular physical 'engineering' the same crap shoot as software engineering.
I think even that is highly romanticised by people. Take Boeing's two big blunders in recent years. The Max and Starliner both had terrible terrible software practices that were "by the book". The problem is "the book" really changed a lot, and the behemoths haven't kept up.
It used to be that "the NASA way" was the most reliable way to build software, and there are still articles and blog posts shared here about the magical programming "rules", but frankly they've been left behind by the industry. On the Starliner project Boeing was seen as the "stable, reliable, tried and true" partner, while Dragon was seen as the "risky" one. Yet Boeing doing everything by the book had 2 loss of crew problems in their first uncrewed demo flight, one relating to software timers, and their crewed demo flight was plagued by problems root-caused to a lack of integration testing. Again, everything by the book, and they failed multiple times on the happy path! The book has to be rewritten, taking into account what the software industry (tech) has "learned" in the past decades. Just think about man-hours and amounts of billions that went into tech software engineering and you can see that obviously NASA can't keep up.
Real engineering doesn't mean that mistakes are never made or that there are never bugs. Rather, it is that systems are tested thoroughly enough, and designed with enough failsafes and redundancy, that safety concerns are mitigated.
The problem in the Boeing case was not that the software had bugs. Lots of aviation software has bugs, it's actually very common. Rather, the problem was that they did not design the system to be safe in the event a bug occurred.
How that looks exactly tends to differ depending on the system. As a common example, many aircraft systems have other systems which monitor them and emit a warning if they detect something which doesn't make sense. Though this would've required Boeing to create technical material for pilots on how to respond to this new type of warning, which would've required training updates, which would've required recertification of their plane design, the cost of which Boeing desperately wanted to avoid. Fortunately (unfortunately), FAA oversight had become very lax, so Boeing instead just downplayed the safety concerns and nobody asked any questions.
I think we've reached the point where this is no longer true - self driving cars, supposed robots you can take home, LLMs being unleashed to randomly guess at medical data or write software to do verification or sensitive tasks.
I think software engineering is definitely engineering, we've just been successful in lobbying against proper regulation. But all that is changing, the EU is introducing the Cyber Resilience Act and I think we need a lot more of that.
Software can be engineered, but It’s rare and expensive so it’s only built that way when the cost is justified, as when building life critical systems (manned aircraft/spacecraft flight controllers) or security critical components like ssl stacks, cryptographic algorithm implementations, etc.
I don't believe in UFOs. But if I had to believe in UFOs, this would be my position:
We have had modern humans for 500 000 years [1]. If it takes 10 000 years to make it from stone age to space age, we have theoretically had time to make that 50 times over. Maybe there was a previous version of a human civilization [2], then wiped out by ice ages or something, but a small number of highly advanced humans have survived and keep hiding from us. I think this could be somewhat more plausible than interstellar travel.
[1] Or maybe 1 million https://news.ycombinator.com/item?id=45510582
http://lambda-the-ultimate.org/node/5335
We just tinker. That's all we can do to get stuff done.
Programmers hate it and rejected it.
To be fair, it does tend to create its own pathology. Instead of a layer cake made of congealed spaghetti, you tend to get over-engineering.
https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...
Software engineering leads to software over-engineering because unlike in physical material engineering there is no capital or material cost to push back against complexity. You can just add things, and add things, and add things, forever, and it costs very little (a bit of RAM and CPU but that's cheap).
I have this weird hypothesis that part of why methodical "correct" software engineering fails is that it succeeds. It is able to manage complexity, which allows complexity to grow without bound. A mountain of ugly shit will start crashing in mysterious ways if it gets too complex, which has the virtue of limiting complexity.
A root problem is that programmers tend to add complexity, not remove it, and the incentive structure of the software business tends to encourage this. Each new bit of complexity or layer is something you could build a business around, or a feature you could sell. Nobody pays for simplicity. It has value, often massive value, but it's not intuitive. In what other domain would you pay more for the absence of something? This would make sense in software since simplicity is harder than complexity, but it feels weird and wrong.
Interesting thought that. Makes a lot of sense. Will remember it the next time I randomly have a train of thought about software complexity on the bus... Am I normal? does everyone here do that? Of course outside hackernews this is a hopeless question.
He said that programming today is “More like science. You grab this piece of library and you poke at it. You write programs that poke it and see what it does. And you say, ‘Can I tweak it to do the thing I want?'”. The “analysis-by-synthesis” view of SICP — where you build a larger system out of smaller, simple parts — became irrelevant.
When I looked at SICP I saw one thing: an introduction to “thinking about programming” for people who will have to re-learn everything and will maybe use a few things here and there. The fundamentals matter but the application is the “everyone has a plan until they get punched in the face” phase of actual learning. There are much better ways to go about studying and learning and I found SICP lacking, among other course work that I think is taught backwards and makes it hard to reason and apply.
Read “Great Programmers” by Bram Cohen. The wisdom is there, but it’s lost on people.
Just my 2c.
Anecdotal, I had a coworker working on a new feature in a huge code base. I was trying to ignore the pseudocode planning they put on the board. After a moment of frustration I wrote down 6 conditionals that simplified what would become hundreds of new lines, to those 6 statement, and capture a few more corner cases they had not worked out yet.
Months later I got a green light on a total overhaul of the larger code base and we turned a massive code base into a fully automated and effectively bullet proof distributed system because I took the time to apply engineering principles to.the problem. The code wasn't always the most proper (I did things downright sinful) but the system was organized like an engineering project with interdependent subsystem instead of a rube Goldberg kludge of new.function on old. That overhaul too less time than any of the prior incremental feature updates prior.
Everything is aliens and a government cover up to those folks....even when you prove it's a floating trash bag they think you're a fool. There are a few rational commenters, but a lot of people that want to believe so bad they fall for all these grifters selling pseudoscience books and seminars.
That's a pretty annoying sampling bias and doesn't reflect the community as a whole. There's plenty of rational voices that think most things are just balloons and drones, but they don't comment when it's boring and mundane. In those cases, only schizo voices remain.
The "alien mummies" and "Buga sphere" came from South America, for instance. You can find UFO and alien contact reports from all over. Brazil has the Varginha incident, the Ariel School incident in Zimbabwe, the Voronezh UFO incident in Russia, Japan Airlines Flight 1628, to name a few examples. The UFO phenomenon isn't at all limited to the US.
Although to be fair, all of that's probably the result of American pop cultural influence.
It plain isn't and to claim that it is shows that you have done EXACTLY 0 research into the topic. This kind of bad faith engagement shows an utter lack of curiosity.
UFOs are huge in South America within just seconds you can find hundreds of sightings and discussions about them:
https://en.wikipedia.org/wiki/Varginha_UFO_incident
https://en.wikipedia.org/wiki/UFO_sightings_in_Brazil
https://www.vice.com/en/article/i-went-alien-hunting-on-chil...
Ufos are also a thing above Europe with the Belgian Ufo wave and the Rendlesham Forest incident being well known and seminal cases in UFO Lore
https://en.wikipedia.org/wiki/Rendlesham_Forest_incident
https://en.wikipedia.org/wiki/Belgian_UFO_wave
Africa also had for example the ariel school incident in Zimbabwe, one of the most well known UFO cases ever
https://en.wikipedia.org/wiki/Ariel_School_UFO_incident
https://en.wikipedia.org/wiki/UFO_sightings_in_Africa
Same goes for russia where after the cold war ufo sightings were discussed in offically declassified documents:
https://www.cia.gov/readingroom/docs/DOC_0005517761.pdf
Must I go on or is that enough to accept that "UNKNOWN THING IN SKY DOES WEIRD THING I DON'T UNDERSTAND" is pretty much a global phenomenon that can and should be scientifically investigated just the same as we would investigate everything else we find anomalous?
You don't notice it do you? Re-read again what I wrote. At no point did I argue that it's aliens. Intentionally.
You first point was proven wrong instantly "it's only an USA Phenomenon". You don't bother to research anything but stick with your hypothesis. You don't even go look for evidence yet are utterly convinced of the result of your complete lack of research.
Here's an example of metal alloy that's supposed to come from an UFO and shows an interesting composition we cannot replicate. It's a well known artefact:
https://tothestars.media/de-de/blogs/press-and-news/tts-anal...
It had some analysis done by different researchers https://www.researchgate.net/publication/237233241_Compositi...
Your lack of curiosity is still very obvious.
What are your thoughts about multiple pilots in formation seeing things that are corroborated by optical, laser, and radar sensors used by the local aircraft and remote radar platforms?
Because that's where things get fun! :)
They're not. There are however two factors greatly biasing your perception of UFOs. First, it takes a fair amount of effort to track down information in foreign language sources, so in general there's going to be a lot less English-language information on Chinese, Russian, or Japanese reports of UFOs. Second, militaries are going to both generate more UFO reports (thanks to military research programs that go awry, e.g., the circumstances behind the Roswell incident) and be a lot more open to collecting and investigating them (because of their ability to indicate the previous point). The US military being the largest and most well-funded in the world is thus going to generate the largest UFO report halo around it.
I don’t know why this keeps coming up, maybe slow news day. It’s okay to be passionate about a craft or a job and for that job to be very technical and demanding. Many people feel that way about what they do, and they are perfectly okay not being engineers.
How much of modern software practices would exist today if the senior engineer needed to sign off on a project?
To be fair, software engineers can face similar liabilities in highly-regulated fields. When you're dealing with software regulated as a medical device for example, senior engineers do sign off on releases. You also see more processes associated with engineering carried out, particularly with respect to testing and documentation.
Here's an example I found enlightening: It's about the HTTP3& the QUIC protocol: https://www.youtube.com/watch?v=4rYPXgCKamM So much real engineering went into that, from fossilized infrastructure that doesn't allow certain ipv6 extension headers, to assumptions about the great firewall of china and it's inner workings and more.
Technically, we're a mature discipline. The author laments our lack of tools as advanced as architectural CAD systems, but I'm unconvinced. We have static types, tests, linters, version control, benchmarks, standard data formats and protocols, deployment orchestration, debuggers. It's pretty nice.
Socially, our discipline feels immature. As mentioned, we don't know how well TDD works, how best to write documentation, or how to pick a flavor of agile. But these are meta-problems that plague every discipline! I challenge you to find a high quality study comparing imperial vs metric units in architecture, or the ideal number of architects for a given project size.
Scientists take reality observations and make theories/models/principles. Engineers take scientific principles and make technological designs. Builders take available technologies and make a product/object/_thing_.
In each level, understanding how your inputs work defines the minimum criteria of success, but those who take the time to understand the “why” are largely considered “the good ones”.
And the rest is turtles all the way down.
For counter-examples see:
https://www-cs-faculty.stanford.edu/~knuth/taocp.html
and
https://www.youtube.com/watch?v=bmSAYlu0NcY
which is about the wonderful book:
https://www.goodreads.com/book/show/39996759-a-philosophy-of...
There are plenty of activities that are essential for engineering but not a sort of engineering themselves. Like writing documentation, or communicating requirements to your colleagues. Making instructions and operational procedures. Management. Accounting. Marketing. What makes making software an engineering discipline and making coffee not? Where is the line and why we presume we should be behind that line?
I tend to disagree with most of these rulesets that are meaningless to "engineering". The idea that a function should only be 40 lines long is offensive to me. Personally, I would rather have one 400 line function than ten 40 line functions. I'm a Ziguana. I care about handling edge cases and I think my programming language should be a domain specific language to produce optimal assembly.
I would not constrain other people who feel differently. I read an article where some project transitioned from Rust to Zig, even though the people on the team were all Rustaceans. Obviously their Rust people hated this and left! To me, that's not a step in the right direction just because I prefer Zig to Rust! That's a disaster because you're taking away the way your team wants to build software.
I think hardly any of the things we disagree on actually have much to do with "Engineering". We mostly aren't proving our code correct, nor defining all the bounds in which it should work. I personally tend to think in those terms and certain self-contained pieces of my software have these limits documented, but I'm not using tools that do this automatically yet. I'd love to build such tools in the coming years though. But there's always the problem that people build tools that don't notice common use-cases that are correct, and then people have to stop doing correct things that the tool can't understand.
Most time spent by people with engineering degrees and job titles, is involved in things like organizing and arranging things, fitting things together, troubleshooting, documentation, meetings. Doing "hard" quantitative engineering is rare, and a lot of the calculations have been rolled into the CAD software. Unless designs are really critical, it's possible to solve problems by the rule of "when in doubt, make it stout."
Is this OK? I think it's an outgrowth of the rising complexity of products. As the number of pieces rises by O(n), the number of interactions goes as O(n*2), so at some point the dominant effort is managing interactions between pieces, rather than engineering the pieces.
Section 3 has about 100 pages (in the pdf - I'd have to dig around to find the hard copy) that tries to look into what computer science is. Section 3.10 starts comparing it with engineering... and noting that it's looking at computer science rather than programing aspect of it. Part of the questions being asked is "is computer science a science?"
I'm going to highly recommend the book for those interested in these questions. I'll also point out that across its thousand(!) pages, this book is in large part a survey of the literature of tens of thousands of more pages on the subjects.
I don't believe that most people are approaching software development (be it called computer science or software engineering) with either the mindset of a scientist or an engineer (there are times when one of those mindsets is necessary) Rather, I agree with a later section in it...
3.14.7 Is CS Magic?
The great science-fiction author Arthur C. Clarke famously said that “Any sufficiently advanced technology is indistinguishable from magic” (http://en.wikipedia.org/wiki/Clarke’s_three_laws). Could it be that the advanced technology of CS is not only indistinguishable from magic, but really is magic? Not magic as in tricks, but magic as in Merlin or Harry Potter? As one CS student put it,
Computer science is very empowering. It’s kind of like knowing magic: you learn the right stuff and how to say it, and out comes an answer that solves a real problem. That’s so cool. —Euakarn (Som) Liengtiraphan, quoted in Hauser 2017, p. 16
Brooks makes an even stronger claim than Clarke:
The programmer, like the poet, works only slightly removed from pure thought-stuff. He [sic] builds castles in the air, creating by the exertion of the imagination . . . . Yet the program construct, unlike the poet’s words [or the magician’s spells?], is real in the sense that it moves and works, producing visible outputs separate from the construct itself. . . . *The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.* (Brooks, 1975, pp. 7–8, my emphases).
...
Clearly, programming involves exactly that kind of use of symbols. Or, as Abelson & Sussman put it in their introductory CS text (which we discussed in §3.14.4): A computational process is indeed much like a sorcerer’s idea of a spirit. It cannot be seen or touched. It is not composed of matter at all. However, it is very real. It can perform intellectual work. It can answer questions. It can affect the world by disbursing money at a bank or by controlling a robot arm in a factory. *The programs we use to conjure processes are like a sorcerer’s spells.* They are carefully composed from symbolic expressions in arcane and esoteric programming languages that prescribe the tasks we want our processes to perform. (Abelson et al., 1996, my italics)
the idea that all, or even most, "software engineering" is real engineering is laughable
Zigurd•2h ago
Marshferm•2h ago
layer8•1h ago
(Not to diminish good craftsmanship, which I highly value.)
Marshferm•1h ago
iberator•1h ago