7 ms·

The analogy between software "engineering" and structural engineering is used a lot to point out the failures of software. I think this analogy is a category mi

The analogy between software "engineering" and structural engineering is used a lot to point out the failures of software. I think this analogy is a category mistake caused entirely by the misapplication of the word "engineer" to software developers. We have already solved large areas of common classes of bugs at the language level, through strong static typing, memory safety and safe concurrency (Rust is the vanguard here but there are lots of languages that tackle these problems in effective ways). Institutional inertia (technical debt) is the only reason why we can't apply these solutions to all software. I work on a PHP app with code that goes back 15 years. To convert it to rust we'd have to invest basically the same as the operating cost of the company. That'll never happen. Once "safe" languages are used, there are still bugs of course. But what are those bugs? Failures of thought, plain and simple. Structural engineers work within the limits of physical reality and these constraints greatly limit the range of possible creation, thus also the range of possible failure. Software has limits too, in memory, storage and processing capacity. But otherwise it works entirely in the realm of pure thought. Well defined specifications that can be turned into concrete tests can solve a lot of these problems, too. (But this is also very expensive). But even if you have specs and tests, there is no magic formula for ensuring your ideas are always sound. If the idea is wrong you can't even write tests to ensure it's correct. "Correctly" functioning components can have complex, difficult to predict side-effects when composed into complex systems. We do have everything we need to write highly reliable software. But solving the software failure problem is the same task as solving the erroneous thinking problem. I don't know that we meat-sacks can "solve" that problem.

pron 7y ago
> there is no magic formula for ensuring your ideas are always sound. If the idea is wrong you can't even write tests to ensure it's correct. There are two parts to this. A wrong idea as in building the wrong product, and a wrong idea as in building the product wrong. There aren't any mechanical processes to protect against the first, but building the wrong product is rarely catastrophic (maybe only from a business perspective), and even if it is, it is usually not the software developer's fault. But as to building the product wrong, there are processes and tools that can help -- a lot -- like TLA+, which is slowly gaining momentum and has completely changed the way I think about software. Tools like TLA+ are extremely powerful at tackling those "complex, difficult to predict side-effects when composed into complex systems", but they don't replace careful thinking, they only help you with attacking complexity once you have decided to think hard about the problem. Getting developers to think hard before or during the development process -- but not while typing code -- is a cultural shift.
- bcheung 7y ago
  TLA for the curious. https://learntla.com/introduction/ https://learntla.com/introduction/
degenerate 7y ago
I've heard the analogy of a software developer to a mechanic, and I like it much more. Developer = Mechanic Computer = Car Make = Language Model = Platform Year = Version A mechanic is licensed by ASE to work on cars in the USA and there are 50 different certifications [1], depending on the type of car/truck/bus. I don't want to see software development go this route, where developers have to get multiple certifications to prove they can work on a language or platform. It would be draining and force devs into silos, even more than they already are. And as the parent comment mentions, software is an "idea" problem and not a structural/foundational one. Unless your developer is a certified genius, what good is his certification? [1] https://en.wikipedia.org/wiki/Automotive_Service_Excellence https://en.wikipedia.org/wiki/Automotive_Service_Excellence
- pjmlp 7y ago
  It is already like that in the enterprise, where certifications are the entry point for certain partnerships. As engineer I find there should be a baseline. I also don't expect weekend cooks to keep a Michelin restaurant running.
- Spooky23 7y ago
  That happens already. As things stabilize you tend to value predictability. You can have 6-10 smart people do the architecture and design work that drives the work of hundreds of developers. Programmers want programming to be about ideas, but many/most problems are applying patterns to process.
- maximus1983 7y ago
  I don't like car analogies. A software engineer is like a plumber you link up lots of small components, weld them together and then the data flows through the application (at least that is the idea).
  - avgDev 7y ago
    I don't like either of these analogies. Work of SE is much more complicated. I guess a developer who just mashes things together on the front end is kind of like a plumber. However, if you work with the backend, you need to worry about data access, any concurrency issues, performance problems. Generally tradesman follow relatively simple guidelines, which may change at a slower pace....tech on the other hand changes insanely quickly.
_bxg1 7y ago
None of the above changes the discussion. It's a very elaborate way of saying "writing correct software is hard". You know what's also hard to do correctly? Designing airplanes. Building skyscrapers. It's not that their designs are made flawless, it's that (in theory) the sheer volume of man-hours spent pouring over every minute detail of them, incorporating lessons learned from every failure that's ever happened in the field, amount to a very very high success rate. In software the mentality is that tests, or formal specs, or even thoughtful design, are luxuries. That it's better to just hire someone who can make the computer do things than spend twice as much on someone who can write "good" code and take twice as long to do so (whatever "good" means, because we have no standard). Of course for "the Uber for X" those standards may be fine. But for autonomous vehicles, or credit bureaus, or the nascent private space industry, they are absolutely not.
- JoeSmithson 7y ago
  Perhaps one of the reasons for this is that software doesn't allow humans any way of leveraging our evolved "danger detectors". It's hard to make a safe building, and it's hard to make safe software. The difference is it's (often) incredibly obvious that a building isn't safe the moment you step into it. In software it's sometimes pretty much impossible to tell the difference between a stone temple and a house of cards.
  - _bxg1 7y ago
    That's not really true. Much of what makes a modern construct safe is extremely unintuitive; material science being a big example. Some modern buildings are even designed to look precarious on purpose, for aesthetic effect, despite being very sound.
  - bcheung 7y ago
    It is incredibly obvious to people with the knowledge and skills. They can look at code and just by glancing at it can have a gut reaction that triggers red flags. Sometimes it can even be an emotional disgust. It's just not common knowledge. We as a community need to do a better job at transferring this knowledge. Proper strong typing, not just the weak typing that is more common, provides these "danger detectors". It makes it a compile error. Compiler errors make things immediately obvious. Type systems are very rich and most statically typed languages that are commonly used now can barely count as type systems when compared against what we know from mathematics and computer science. They merely describe the data format (or not in the case of nullable) and not acceptable inputs. They don't allow types for scenarios like requiring a function that exhibits these behaviors but not these other ones. Pattern matching in combination with strong typing requires code that handles all possible inputs or you get a compiler error. Dependent typing requires inputs to be within certain tolerances (not just adhering to a data format). Type systems can also make certain race conditions impossible to create.
la_barba 7y ago
There is another problem, that software developers in general hate maintenance work. People should be working on keeping existing stuff working and well-oiled. We want exciting work where we get to learn some new tech. Nobody wants the janitorial jobs where you're just keeping things ticking along and running smoothly. Ofcource there are people who work on legacy systems - banking systems, old mainframes, etc. We already have so much software thats out there, that just goes unused, and then people "re-invents" it, and often times makes it worse - with DRM, subscription, micro-transactions, "but now its on the web", etc.
- swiftcoder 7y ago
  I'd argue that there are an awful lot of us who would like nothing better than to spend our time cleaning up the codebase, refactoring risky code, getting the whole thing under test, etc. Unfortunately, most organisations only grudgingly fund such work, and if I were to spend a significant portion of my time on such work (without being on a team dedicated to a critical modernisation effort), my performance reviews and compensation would suffer accordingly.
  - ScottFree 7y ago
    Bingo. Hell, I'd love to do nothing but maintenance work, but I'd have a hard time paying the bills that way.
- deleted 7y ago
  [deleted]
2_listerine_pls 7y ago
> the misapplication of the word "engineer" to software developers. Is it? you didn't say how it's misapplied.
gautamdivgi 7y ago
Reminds me of Michael A. Jackson's paper [0]. He specifically discusses this very same issue. I think it was posted on HN a while back but can't dig up the link. 0. http://mcs.open.ac.uk/mj665/FoSEZurich2010.pdf http://mcs.open.ac.uk/mj665/FoSEZurich2010.pdf
pjmlp 7y ago
We could start by not allowing pseudo-engineers out of bootcamps. Yes, specs and tests don't cover everything, however without them software is much worse. I guess only an increase in lawsuits and product returns will eventually change the status quo.
- tashoecraft 7y ago
  Why? Because those with CS degrees don’t make mistakes either? Or how about self taught engineers, do they not count? A problem is software is so easily created, destroyed and refactored. Combined with business interests pushing for all sorts of things midway through. How often are bridges built halfway when their entire spec changes, oh just convert his half done 2 lane bridge to a 4 lane double decker, should be no problem right? That’s how we treat software.
  - pjmlp 7y ago
    Engineering is a professional title, with a set of requirements that express a certain level of skill, moral and ethics. Self taught, yes if they can attain the expected level of the Engineering Order.
oldjokes 7y ago
Typing systems and language choices are really small potatoes in this field. There are much more scary problems to solve to make software work right. When you can side channel attack any CPU with a branch predictor and bits get flipped regularly by cosmic rays at high altitude then you need to rethink what software engineering really means. The big problems are rarely actually about the software or proving some algorithm is correct.
- bcheung 7y ago
  Ah yes, real engineers anticipate the side channel attack that can happen when someone releases a butterfly at precisely the right location and precisely the right time so that it flaps its wings that affects the climate 10 years later that affects the cosmic rays that cause electrons to misbehave in all the CPUs across all the Docker containers on all the hosts in all the data centers and availability zones that causes all the right double entry debits and credits across multiple bank accounts and across multiple banking companies to steal some money. This is a much bigger problem than type safety. But luckily that is a hardware problem.
  - deleted 7y ago
    [deleted]
  - deleted 7y ago
    [deleted]
tracker1 7y ago
Agreed. Also, there's a big difference in building a doghouse, tent, home and skyscraper or bridge. Not all of them require the same rigor and planing. Beyond this, a lot of organizations don't allow for pushback from development to cover for clearing technical debt. None of this accounts for the fact that over half the software industry has less than 5 years of experience and less than 25% has over 10. People with less than 5-10 years of experience can be brilliant, but there are things you learn with experience. First and foremost is the ability to push back and say, "No, it can't reasonably be done in X timeframe." Actually using scrum process to break things down in to chunks that can be swallowed. Not allowing mid-level developers to use "enterprise patterns" everywhere, especially when they increase complexity and fail to provide real value to the project. Preplanning and the level it takes will depend on the scope of the project and the use case. A heart monitor or guidance system isn't the same as an eCommerce or entertainment website. Engineering discipline isn't required for the latter, but is for the former examples.
danielscrubs 7y ago
In my country, all engineers are protected titles and basically just says you spent half of your 3 or 5 years studying math. Not even algorithms, just math. Makes it very confusing when teens calls themselves SEs

pron 7y ago

> there is no magic formula for ensuring your ideas are always sound. If the idea is wrong you can't even write tests to ensure it's correct. There are two parts to this. A wrong idea as in building the wrong product, and a wrong idea as in building the product wrong. There aren't any mechanical processes to protect against the first, but building the wrong product is rarely catastrophic (maybe only from a business perspective), and even if it is, it is usually not the software developer's fault. But as to building the product wrong, there are processes and tools that can help -- a lot -- like TLA+, which is slowly gaining momentum and has completely changed the way I think about software. Tools like TLA+ are extremely powerful at tackling those "complex, difficult to predict side-effects when composed into complex systems", but they don't replace careful thinking, they only help you with attacking complexity once you have decided to think hard about the problem. Getting developers to think hard before or during the development process -- but not while typing code -- is a cultural shift.

bcheung 7y ago
TLA for the curious. https://learntla.com/introduction/ https://learntla.com/introduction/

degenerate 7y ago

I've heard the analogy of a software developer to a mechanic, and I like it much more. Developer = Mechanic Computer = Car Make = Language Model = Platform Year = Version A mechanic is licensed by ASE to work on cars in the USA and there are 50 different certifications [1], depending on the type of car/truck/bus. I don't want to see software development go this route, where developers have to get multiple certifications to prove they can work on a language or platform. It would be draining and force devs into silos, even more than they already are. And as the parent comment mentions, software is an "idea" problem and not a structural/foundational one. Unless your developer is a certified genius, what good is his certification? [1] https://en.wikipedia.org/wiki/Automotive_Service_Excellence https://en.wikipedia.org/wiki/Automotive_Service_Excellence

pjmlp 7y ago
It is already like that in the enterprise, where certifications are the entry point for certain partnerships. As engineer I find there should be a baseline. I also don't expect weekend cooks to keep a Michelin restaurant running.
Spooky23 7y ago
That happens already. As things stabilize you tend to value predictability. You can have 6-10 smart people do the architecture and design work that drives the work of hundreds of developers. Programmers want programming to be about ideas, but many/most problems are applying patterns to process.
maximus1983 7y ago
I don't like car analogies. A software engineer is like a plumber you link up lots of small components, weld them together and then the data flows through the application (at least that is the idea).
- avgDev 7y ago
  I don't like either of these analogies. Work of SE is much more complicated. I guess a developer who just mashes things together on the front end is kind of like a plumber. However, if you work with the backend, you need to worry about data access, any concurrency issues, performance problems. Generally tradesman follow relatively simple guidelines, which may change at a slower pace....tech on the other hand changes insanely quickly.

_bxg1 7y ago

None of the above changes the discussion. It's a very elaborate way of saying "writing correct software is hard". You know what's also hard to do correctly? Designing airplanes. Building skyscrapers. It's not that their designs are made flawless, it's that (in theory) the sheer volume of man-hours spent pouring over every minute detail of them, incorporating lessons learned from every failure that's ever happened in the field, amount to a very very high success rate. In software the mentality is that tests, or formal specs, or even thoughtful design, are luxuries. That it's better to just hire someone who can make the computer do things than spend twice as much on someone who can write "good" code and take twice as long to do so (whatever "good" means, because we have no standard). Of course for "the Uber for X" those standards may be fine. But for autonomous vehicles, or credit bureaus, or the nascent private space industry, they are absolutely not.

JoeSmithson 7y ago
Perhaps one of the reasons for this is that software doesn't allow humans any way of leveraging our evolved "danger detectors". It's hard to make a safe building, and it's hard to make safe software. The difference is it's (often) incredibly obvious that a building isn't safe the moment you step into it. In software it's sometimes pretty much impossible to tell the difference between a stone temple and a house of cards.
- _bxg1 7y ago
  That's not really true. Much of what makes a modern construct safe is extremely unintuitive; material science being a big example. Some modern buildings are even designed to look precarious on purpose, for aesthetic effect, despite being very sound.
- bcheung 7y ago
  It is incredibly obvious to people with the knowledge and skills. They can look at code and just by glancing at it can have a gut reaction that triggers red flags. Sometimes it can even be an emotional disgust. It's just not common knowledge. We as a community need to do a better job at transferring this knowledge. Proper strong typing, not just the weak typing that is more common, provides these "danger detectors". It makes it a compile error. Compiler errors make things immediately obvious. Type systems are very rich and most statically typed languages that are commonly used now can barely count as type systems when compared against what we know from mathematics and computer science. They merely describe the data format (or not in the case of nullable) and not acceptable inputs. They don't allow types for scenarios like requiring a function that exhibits these behaviors but not these other ones. Pattern matching in combination with strong typing requires code that handles all possible inputs or you get a compiler error. Dependent typing requires inputs to be within certain tolerances (not just adhering to a data format). Type systems can also make certain race conditions impossible to create.

la_barba 7y ago

There is another problem, that software developers in general hate maintenance work. People should be working on keeping existing stuff working and well-oiled. We want exciting work where we get to learn some new tech. Nobody wants the janitorial jobs where you're just keeping things ticking along and running smoothly. Ofcource there are people who work on legacy systems - banking systems, old mainframes, etc. We already have so much software thats out there, that just goes unused, and then people "re-invents" it, and often times makes it worse - with DRM, subscription, micro-transactions, "but now its on the web", etc.

swiftcoder 7y ago
I'd argue that there are an awful lot of us who would like nothing better than to spend our time cleaning up the codebase, refactoring risky code, getting the whole thing under test, etc. Unfortunately, most organisations only grudgingly fund such work, and if I were to spend a significant portion of my time on such work (without being on a team dedicated to a critical modernisation effort), my performance reviews and compensation would suffer accordingly.
- ScottFree 7y ago
  Bingo. Hell, I'd love to do nothing but maintenance work, but I'd have a hard time paying the bills that way.
deleted 7y ago
[deleted]

2_listerine_pls 7y ago

> the misapplication of the word "engineer" to software developers. Is it? you didn't say how it's misapplied.

gautamdivgi 7y ago

Reminds me of Michael A. Jackson's paper [0]. He specifically discusses this very same issue. I think it was posted on HN a while back but can't dig up the link. 0. http://mcs.open.ac.uk/mj665/FoSEZurich2010.pdf http://mcs.open.ac.uk/mj665/FoSEZurich2010.pdf

pjmlp 7y ago

We could start by not allowing pseudo-engineers out of bootcamps. Yes, specs and tests don't cover everything, however without them software is much worse. I guess only an increase in lawsuits and product returns will eventually change the status quo.

tashoecraft 7y ago
Why? Because those with CS degrees don’t make mistakes either? Or how about self taught engineers, do they not count? A problem is software is so easily created, destroyed and refactored. Combined with business interests pushing for all sorts of things midway through. How often are bridges built halfway when their entire spec changes, oh just convert his half done 2 lane bridge to a 4 lane double decker, should be no problem right? That’s how we treat software.
- pjmlp 7y ago
  Engineering is a professional title, with a set of requirements that express a certain level of skill, moral and ethics. Self taught, yes if they can attain the expected level of the Engineering Order.

oldjokes 7y ago

Typing systems and language choices are really small potatoes in this field. There are much more scary problems to solve to make software work right. When you can side channel attack any CPU with a branch predictor and bits get flipped regularly by cosmic rays at high altitude then you need to rethink what software engineering really means. The big problems are rarely actually about the software or proving some algorithm is correct.

bcheung 7y ago
Ah yes, real engineers anticipate the side channel attack that can happen when someone releases a butterfly at precisely the right location and precisely the right time so that it flaps its wings that affects the climate 10 years later that affects the cosmic rays that cause electrons to misbehave in all the CPUs across all the Docker containers on all the hosts in all the data centers and availability zones that causes all the right double entry debits and credits across multiple bank accounts and across multiple banking companies to steal some money. This is a much bigger problem than type safety. But luckily that is a hardware problem.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]

tracker1 7y ago

Agreed. Also, there's a big difference in building a doghouse, tent, home and skyscraper or bridge. Not all of them require the same rigor and planing. Beyond this, a lot of organizations don't allow for pushback from development to cover for clearing technical debt. None of this accounts for the fact that over half the software industry has less than 5 years of experience and less than 25% has over 10. People with less than 5-10 years of experience can be brilliant, but there are things you learn with experience. First and foremost is the ability to push back and say, "No, it can't reasonably be done in X timeframe." Actually using scrum process to break things down in to chunks that can be swallowed. Not allowing mid-level developers to use "enterprise patterns" everywhere, especially when they increase complexity and fail to provide real value to the project. Preplanning and the level it takes will depend on the scope of the project and the use case. A heart monitor or guidance system isn't the same as an eCommerce or entertainment website. Engineering discipline isn't required for the latter, but is for the former examples.

danielscrubs 7y ago

In my country, all engineers are protected titles and basically just says you spent half of your 3 or 5 years studying math. Not even algorithms, just math. Makes it very confusing when teens calls themselves SEs