"Software Engineering" Is Not Engineering (2005)(web.archive.org) |
"Software Engineering" Is Not Engineering (2005)(web.archive.org) |
With “classic” engineering at least you have the immutable laws of physics to judge your work, but with software we have no such luck - software is infinitely pliable in ways equivalent to bending the laws of physics in classical engineering. Your bridge may not be sound at one Earth gravity, or your software might not work reliably with a gigabyte of memory, but it’s like we can place your bridge under half G by giving the software twice as much memory. And we can do all that after building our “bridges”.
I would even suggest software engineering can also be described as “applied poetry”, where we write precise prose designed to elicit specific responses from machines, but I guess that analogy was taken by “prompt engineering”, which feels like “applied sorcery”.
The physics works perfectly, of course. But physics is only a third of the constraint in engineering. The other two thirds are project goals and convention.
Project goals are horribly underspecified, every time. It's incredibly rare to be given a project that is completely constrained on that side, and if you do get one, most of the time it's physically impossible to achieve. This is because the people who write those specifications not doing engineering, they're doing marketing or sales or just had a cool idea. Sometimes that can even be the engineer themselves :-) So it's up to the engineer to fill in the gap, and they do it with experience and a sense of aesthetics, of sorts.
Convention is what constrains the physical possibilities of engineering to the practical. Yes, you can build anything and make it work, possibly even better than what everyone else builds. But you will have to invent and construct a lot of new technologies before you can build your perfect mousetrap. So, you settle on standard components and build a decent one instead. But this introduces a gap between physics and engineering, too. A bit of no-man's land that you can reach into to produce truly great results. But it's up to the engineer to know when it's worth it.
* Object oriented / functional * Thick client, thin client * Blockchain * NoSQL vs relational * Enterprise SOA * Framework churn
This industry is continually rediscovering ancient paradigms and revisiting them in a way that would drive normal engineers nuts. I suspect it's because software engineering doesn't actually have requirements around licensure and education that slow and stabilize the arrow of progress.
No - it's just revolving so much faster, in every single sense. And it's only accelerating.
There are programmers who do that, and I think it's the way to make good software, to care about what the machine actually does that is, and not just if it's easier to write one line instead of five (which is where we got this bloated framework mess from)... but it's hardly some sort of standard for the profession, much less the minimum.
With engineering (I would assume), you rarely see, say, some sort of tool (made by an engineer, that is) that has half of another tool sticking out of it in a spot "where it doesn't matter" because they preferred to ship faster. You'll never see a tool that just weighs 100x more than it needs to because hey who cares, it's not like the person who made and sold that thing actually has to use it.
With software, costs are externalized left and right because to see them, you'd have to actively think about stuff, and customers don't know anyway so anything goes, unless you go too far. But if a washing machine is the size of half a city, everyone notices.
> With “classic” engineering at least you have the immutable laws of physics to judge your work, but with software we have no such luck - software is infinitely pliable in ways equivalent to bending the laws of physics in classical engineering. Your bridge may not be sound at one Earth gravity, or your software might not work reliably with a gigabyte of memory, but it’s like we can place your bridge under half G by giving the software twice as much memory. And we can do all that after building our “bridges”.
In that example, software isn't actually "plied" (if that is a word?) though, the amount of RAM is. So the software stays as is, mediocre. And art, like engineering, often benefits from constraints. Imagine if the solution to being a shitty artist would be to just drug the audience so they're happier and like whatever they're seeing more. Even if it benefited them, even if you could tell them and they'd be fine with it, that's not the way to hone a craft, that just seems obvious on the surface to me.
Cool analogies
> Remember "imaginary numbers" from algebra? You could do funky stuff with them like take the square root of negative nine. Imaginary numbers are generally useless for the physical world that we experience. However, they turned out to be very useful in the field of electronics. More specifically, they had predictive power in the field of electronics. Using imaginary number math, one can predict behavior of electrons and the accuracy of such predictions in models can be measured.
Like here, I struggle to understand what the point is. Is predicting the behavior of electronics "useless for the physical world we experience"? And that's ignoring the author's apparent ignorance of all the other ways in which complex numbers are useful in the physical world besides taking negative numbers' square roots.
The article seems to make some fairly confusing statements. Why is the bar higher for software engineering, than that of civil engineering otherwise? Statements such as:
> "there is no objective reality inside software"
> "if there are many solutions to the same problem, which one is "better"?"
Is the exact same subjective goal that a objective engineering constraint has in any other engineering field. There are many ways to design and build a bridge, but the engineering aspect of it needs to model reality and account for it in such a way that the bridge to build conforms to said requirements, in a provable way. That's why engineers can be held responsible when mistakes are made.
Software Engineering can be done in the same way. This, however, depends entirely on the culture. My first decade in the field, I was fortunate to only be exposed to en environment and culture that developed software in a provably correct way, or at the very least, aspired to. The latter decade, not so fortunate. With the advent of generative AI, it's become far worse. The challenge is to carve out enough space outside the purview of "management" that wants problems solved with particular tools, regardless of applicability to said problems, and it's becoming insurmountable. Signal to noise disappearing. The idea of buying land and tending to a farm, evermore appealing.
I wonder if the author perhaps has not worked on software that comes with actual engineering constraints. There are plenty of software systems where <if it doesn't work as it should>, people die.
Overall though I found this post incredibly hard to read. It's incredibly long and wordy though that's par for the course for these petty semantic arguments.
IMO, I’ve never been all that concerned as to whether the “engineer” label should apply to me (coming from an engineering education but mostly looking at software). It’s more about having a professional obligation than any great feats of skill anyway, and since an obligation is mostly just felt in your head, you can give it to yourself.
The engineer title is apt in my opinion, because if you look at construction as a parallel, the architect designs the shape of the building, engineers determine how to build it so it doesn't collapse, and builders actually make it real. Programming is like digital building, the architecture and implementation details are both separate.
Language is for us, not the other way around. It's common usage changes.
We need to stop redefining terms.
I design solutions to computational problems. I also happen to implement them a lot of the time, because code was trivial to implement even before LLMs. What does that make me if not an engineer? I'm open to suggestions.
I'd say software engineering better fits economics these days. Maybe with a Psych major to maximize the dark patterns.
e.g. his 2021 book " Modern Software Engineering"
> Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software.
https://www.davefarley.net/?p=352
https://www.goodreads.com/en/book/show/57345270-modern-softw...
Anything that exists in reality and is observable by definition is tightly bound by the laws of physics and chemistry. Software is too.
>Software is a lot like math,
Probably referring to computer science. Computer science is neither about computers nor is it a science. It is a math. Software is like math but applied.
>The only limitation is the imagination of the creator of the virtual world (and perhaps the pesky limitations of computer resources)
computer resources: AKA physical laws. And these "laws" highly limit us in what we can do. We are definetely not operating in some kind of playground where we can be virtual gods, not even close, that's why entire swe teams are involved and paid a lot in software.
Honestly the main difference between "Software Engineering" and "Engineering" is that software is more an "art". We make up a bunch of technical nomenclature for it (like design patterns which sounds technical but is mostly made up and more artsy then say statistical mechanics) but it's mostly similar to sculpture or some artistic creation as we sort of piece everything together by instinct.
The difference between this and engineering is usually engineering involves mathematical modeling and testing heavily in development, while software engineering (usually) does not involve mathematical modeling and software testing is more of a catch-all to find bugs.
Type checking is mathematical modeling, but I wouldn't call it the core of software engineering. I guess this is where the categories get blurry.
This is definably not engineering.
However, I do have an issue with his focus on applying science in the definition, even though it doesn't come across in his final conclusions. In the history of engineering, that's a relatively new development. It started, to some extent, in Europe in the 1700s, but it really took off in the 1920s and exploded in the United States after World War II (1940s-1950s). It culminated with the Report of the Committee on Evaluation of Engineering Education (the Grinter Report) in the mid-1950s.
This isn't to say that science isn't important to engineering, since it absolutely is. Science provides knowledge used to better understand the world being changed by engineering. But there are also plenty of examples of engineering going ahead of science - the steam engine, the airplane, generative AI. We didn't fully understand the governing rules before the technology existed.
Any definition of engineering needs to be broader. Ferguson (Engineering and the Mind's Eye), Florman (several works, but primarily The Existential Pleasures of Engineering), and Vincenti (What Engineers Know and How They Know It) all explore ways in which engineering can't rely on science alone. I think Koen (Discussion of the Method) puts it best, where the application of science is one heuristic that engineers may choose to draw upon.
I don’t think it’s about science. It’s about the scientific method. From wikipedia
The scientific method is an empirical method for acquiring knowledge through careful observation, rigorous skepticism, hypothesis testing, and experimental validation
it absolutely can, approximately nobody was doing that because it was insanely expensive. if we narrow down the definitions, modern static typing (where modern means universally accepted nowadays) is a form of mathematical modeling and proof construction that software does what it says it does.
the economic calculation is changing extremely rapidly now with LLMs though. some of my software is now proved to be correct at some levels, e.g. I heavily (that is, LLMs I pilot) use TLA+ for tricky but nowhere near foundational distributed systems work (as in, I don't work on core S3, but do distributed transaction stuff).
Agreed. If I have to guess, the relevant fields in physics for software engineering would be quantum mechanics and thermodynamics. Of course, we don't see any direct relation as of now but it feel it should be important to determine the physical basis of software. The basis of software cannot be just math. It has to be physics.
> Anything that exists in reality and is observable by definition is tightly bound by the laws of physics and chemistry. Software is too.
No. Software is only loosely bound by physics and chemistry. Sure, the bounds exist - they're real - but most software, most of the time, does not bump into them much at all.
But
> > An engineer's model must be tightly bound to the laws of physics and chemistry.
is also wrong. This is using a pre-software definition of engineering to try to define software engineering. It would be like trying to use a pre-Faraday definition of physics to define microwave engineering.
I've held an "engineer" title at my day job from time to time, though I'm not an engineer and have no engineering degree. Only a couple of engineers at my work site have licenses. On the other hand, my brother in law was a nuclear engineer, and all of the engineers at the power plant were licensed.
One thing you'll notice is that small companies that do contract or consulting work will call themselves "research" or "technology" rather than using the E word on their web page.
I've never heard "instinctively doing things without conscious choice" to be engineering. That opens it up so wide it's meaningless - is blinking to rewet my eyeballs engineering? How about farting to relieve internal pressure?
And "empirical" explicitly means you consciously understand the reasons, so your comment is self-contradictory as well. Basically, words have meanings and you don't seem to know them.
I could be stretching, but to me, this is very conscious and intentional work, perfected through experience and there are many way to get it wrong. What exactly would we call this?
I studied at a technical university at its faculty of electrical engineering, but those who study at a "normal" university indeed go through the usual three years and are not engineers.
I guess the main difference is that I learned about analog circuits, semiconductors and all that, while those other guys didn't.
I don't have any special professional certificates, though I could optionally enroll on a course allowing me to work with voltages up to 1000V.
The title "ingénieur" is not regulated, it is a job title and anyone can have it if the position calls for it.
What is regulated however is the engineering degree ("diplôme d'ingénieur"), only some schools recognized by the state ("grandes écoles") can deliver it. It gives you the right to call yourself "ingénieur diplômé". Internationally, it counts as a masters degree.
As far as I know, it is a french system with no equivalent in other countries, and I don't know of any foreign school, even among the most prestigious that can deliver a "diplôme d'ingénieur".
Administratively, regulated professions (including doctors, lawyers, architects, etc... but not engineers in general) are regulated by the ministry of work, while the engineering degree is regulated by the ministry of education.
I am well aware of all that because my school (EPITA) went through the process of getting approval from the "Commission des Titres d'Ingénieur" while I was studying there so it was a pretty hot topic. The result is that I don't have a "diplôme d'ingénieur" (but I have a "degree in engineering", equivalent to a regular masters degree, love the play on words) but the next promotions do. My job title is still "engineer" in any case.