3 ms·

Why not? A simple one line change recently brought down CloudFlare. And least you think that's not important, a one line change to code brought down most of A

by spc476 4y ago

Why not? A simple one line change recently brought down CloudFlare. And least you think that's not important, a one line change to code brought down most of AT&T's phone network in 1990 (think 911).

throwaway290 4y ago
Compare the amount of effort that goes into both design and production of a physical part and a line of code. A single physical part generally has many, many inputs and outputs (expressed as its physical contact surfaces, tolerances, forces and stresses of all possible kinds from all directions they are supposed to withstand, etc., all with the added dimension of time) compared to a line of code or even a function. You cannot design a 'functionally pure' part, or design a part that creates itself for every discrete 'use'. And unlike a line of code, it can't be quickly replaced so you must get it right. And if you get it wrong, people may die in this particular example. Etc. And that's before we become concerned with actual production of that part, whereas all you need for to write a line of code is a text editor or pen and paper.
- chrisco255 4y ago
  Software has analogous constraints, with regards to scale, performance, latency, design, etc. Everyone thinks that a line of code can be quickly replaced. On a small program, this is true. But at scale, this is not true at all and anyone that's worked on a multi-million line application knows this. You cannot have every line of a complex system in your head at once. You cannot instantly solve for all of the interconnecting pieces in your mind at once. It takes a team of software engineers of various disciplines to consider the tradeoffs of any change to these complex systems. In particular when they are live and supporting millions to billions of users. And because software has more of an organic quality than traditional hardware, managing hundreds or thousands of changes that need to go into the system over the course of a month or quarter is non-trivial. People that think software is trivial are the same ones that fall for the idea that anything can be quickly refactored and redesigned and nothing will break and everything will go smoothly. It's just not true. Most human beings can handle, at most, 5 to 9 variables in their head at once. Software systems grow to immense complexity of thousands to millions of variables, with various runtimes, databases, caching layers, frameworks, libraries, coding styles accrued over multiple decades in some cases, data aggregation pipelines, dozens to hundreds of APIs with their own unique interfaces, etc. It is a constant battle against entropy, which happens inevitably in such systems. Meanwhile, there isn't a single modern "real engineer" who doesn't get their daily work done thanks to multiple software programs supporting their own productivity so much that they can replace what used to be teams of dozens to hundreds of assistants, techs, engineers, and other various human support systems. They draw lines on AutoCAD that automatically compute moments of inertia, shaft calcs, bill of materials, etc. Then they take that file output and zap it over Slack instantly to their colleague who works from home hundreds of miles away to get their feedback on it. Behind all of that is a team of software engineers and product devs that not only has to understand the constraints of their own technical systems, but the technical needs of their engineering clientele.
  - throwaway290 4y ago
    I'm not arguing EE is better than SE or otherwise. My point is specifically that EE has both more complexity and stricter constraints, and both unavoidable due to the nature of it being mechanical as opposed to ideal. Yes, in SE you also have complexity, but you can abstract it away with many tricks like isolating side effects and writing pure functions that are easy to reason, re-running from clean slate at will at little cost or even running your code anew at every request, letting things fail completely and be sure it's cleaned up reliably, etc. In EE, you have enormous implicit state that you can't ignore, the global of time and everything else all at once you must juggle.
Ekaros 4y ago
Single line of code is single line of code. Physical part might have multiple lines of code defining it. Let's take something relatively simple like bracket. Now gather together all the dimensions, angles, hole dimensions, material specifications of it and treat all of those as their individual lines of code.

by spc476 4y ago

Why not? A simple one line change recently brought down CloudFlare. And least you think that's not important, a one line change to code brought down most of AT&T's phone network in 1990 (think 911).

throwaway290 4y ago

Compare the amount of effort that goes into both design and production of a physical part and a line of code. A single physical part generally has many, many inputs and outputs (expressed as its physical contact surfaces, tolerances, forces and stresses of all possible kinds from all directions they are supposed to withstand, etc., all with the added dimension of time) compared to a line of code or even a function. You cannot design a 'functionally pure' part, or design a part that creates itself for every discrete 'use'. And unlike a line of code, it can't be quickly replaced so you must get it right. And if you get it wrong, people may die in this particular example. Etc. And that's before we become concerned with actual production of that part, whereas all you need for to write a line of code is a text editor or pen and paper.

chrisco255 4y ago
Software has analogous constraints, with regards to scale, performance, latency, design, etc. Everyone thinks that a line of code can be quickly replaced. On a small program, this is true. But at scale, this is not true at all and anyone that's worked on a multi-million line application knows this. You cannot have every line of a complex system in your head at once. You cannot instantly solve for all of the interconnecting pieces in your mind at once. It takes a team of software engineers of various disciplines to consider the tradeoffs of any change to these complex systems. In particular when they are live and supporting millions to billions of users. And because software has more of an organic quality than traditional hardware, managing hundreds or thousands of changes that need to go into the system over the course of a month or quarter is non-trivial. People that think software is trivial are the same ones that fall for the idea that anything can be quickly refactored and redesigned and nothing will break and everything will go smoothly. It's just not true. Most human beings can handle, at most, 5 to 9 variables in their head at once. Software systems grow to immense complexity of thousands to millions of variables, with various runtimes, databases, caching layers, frameworks, libraries, coding styles accrued over multiple decades in some cases, data aggregation pipelines, dozens to hundreds of APIs with their own unique interfaces, etc. It is a constant battle against entropy, which happens inevitably in such systems. Meanwhile, there isn't a single modern "real engineer" who doesn't get their daily work done thanks to multiple software programs supporting their own productivity so much that they can replace what used to be teams of dozens to hundreds of assistants, techs, engineers, and other various human support systems. They draw lines on AutoCAD that automatically compute moments of inertia, shaft calcs, bill of materials, etc. Then they take that file output and zap it over Slack instantly to their colleague who works from home hundreds of miles away to get their feedback on it. Behind all of that is a team of software engineers and product devs that not only has to understand the constraints of their own technical systems, but the technical needs of their engineering clientele.
- throwaway290 4y ago
  I'm not arguing EE is better than SE or otherwise. My point is specifically that EE has both more complexity and stricter constraints, and both unavoidable due to the nature of it being mechanical as opposed to ideal. Yes, in SE you also have complexity, but you can abstract it away with many tricks like isolating side effects and writing pure functions that are easy to reason, re-running from clean slate at will at little cost or even running your code anew at every request, letting things fail completely and be sure it's cleaned up reliably, etc. In EE, you have enormous implicit state that you can't ignore, the global of time and everything else all at once you must juggle.

Ekaros 4y ago

Single line of code is single line of code. Physical part might have multiple lines of code defining it. Let's take something relatively simple like bracket. Now gather together all the dimensions, angles, hole dimensions, material specifications of it and treat all of those as their individual lines of code.