thought: safety - Software Engineering vs other Engineering displanes
-
Saw a comic strip the other day semi-joking about Aeroplanes being relatively safe Bridges being safe then software built voting system - 😭 Several bits come to mind, some obvious like physical access. But one that stands out the most is scale of access. Recent Phillips light bulk hack indicates this train of though. Breaking 1 bit of software potentially allows access to the whole thing. Tampering a plane or bridge to fail are more localised to the one occurrence. But "hack" a tesla, or digital polling station, and the spread risk is high. So yes, funny as a joke, but seriously, it is not so much that software engineering is more poorly implemented (ignoring the 90% of low code quality) then physical engineering disciplines, but have a wider risk effect when flaws exist. In contrast, software flaws can be fixed and updated/spread more rapidly then hardware flaws. How long was the gap between enthusiast plan makers to standardised specification for commercial use? HIPPA offers a bunch of guides (if i understand HIPPA 🤷♂️). How linnet is HIPPA compared to commercial plan requirements?
Have you ever seen an (non-Boeing) aeroplane or bridge being built using the Agile methodology? :)
maze3 wrote:
but have a wider risk effect when flaws exist.
Like grounding an entire fleet of planes? Or recalling all cheeses from the supermarket due to contamination?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Saw a comic strip the other day semi-joking about Aeroplanes being relatively safe Bridges being safe then software built voting system - 😭 Several bits come to mind, some obvious like physical access. But one that stands out the most is scale of access. Recent Phillips light bulk hack indicates this train of though. Breaking 1 bit of software potentially allows access to the whole thing. Tampering a plane or bridge to fail are more localised to the one occurrence. But "hack" a tesla, or digital polling station, and the spread risk is high. So yes, funny as a joke, but seriously, it is not so much that software engineering is more poorly implemented (ignoring the 90% of low code quality) then physical engineering disciplines, but have a wider risk effect when flaws exist. In contrast, software flaws can be fixed and updated/spread more rapidly then hardware flaws. How long was the gap between enthusiast plan makers to standardised specification for commercial use? HIPPA offers a bunch of guides (if i understand HIPPA 🤷♂️). How linnet is HIPPA compared to commercial plan requirements?
when the plane you are on crashes it tends to leave a mark on you, when the bridge you're on crashes it tends to damage the paintwork, when the app you're on crashes it just pisses you off.
after many otherwise intelligent sounding suggestions that achieved nothing the nice folks at Technet said the only solution was to low level format my hard disk then reinstall my signature. Sadly, this still didn't fix the issue!
-
when the plane you are on crashes it tends to leave a mark on you, when the bridge you're on crashes it tends to damage the paintwork, when the app you're on crashes it just pisses you off.
after many otherwise intelligent sounding suggestions that achieved nothing the nice folks at Technet said the only solution was to low level format my hard disk then reinstall my signature. Sadly, this still didn't fix the issue!
lopatir wrote:
when the app you're on crashes it just pisses you off.
That may be true for a lot of them; but sometimes an error may cause financial damage or endanger health.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Saw a comic strip the other day semi-joking about Aeroplanes being relatively safe Bridges being safe then software built voting system - 😭 Several bits come to mind, some obvious like physical access. But one that stands out the most is scale of access. Recent Phillips light bulk hack indicates this train of though. Breaking 1 bit of software potentially allows access to the whole thing. Tampering a plane or bridge to fail are more localised to the one occurrence. But "hack" a tesla, or digital polling station, and the spread risk is high. So yes, funny as a joke, but seriously, it is not so much that software engineering is more poorly implemented (ignoring the 90% of low code quality) then physical engineering disciplines, but have a wider risk effect when flaws exist. In contrast, software flaws can be fixed and updated/spread more rapidly then hardware flaws. How long was the gap between enthusiast plan makers to standardised specification for commercial use? HIPPA offers a bunch of guides (if i understand HIPPA 🤷♂️). How linnet is HIPPA compared to commercial plan requirements?
After 10 years engineering and building a plane: *safety inspectors doing years of rigorous testing in all manner of extreme conditions* After 10 months of engineering and building a website: *our test team seeing the home page doesn't throw a 500 error*
-
Saw a comic strip the other day semi-joking about Aeroplanes being relatively safe Bridges being safe then software built voting system - 😭 Several bits come to mind, some obvious like physical access. But one that stands out the most is scale of access. Recent Phillips light bulk hack indicates this train of though. Breaking 1 bit of software potentially allows access to the whole thing. Tampering a plane or bridge to fail are more localised to the one occurrence. But "hack" a tesla, or digital polling station, and the spread risk is high. So yes, funny as a joke, but seriously, it is not so much that software engineering is more poorly implemented (ignoring the 90% of low code quality) then physical engineering disciplines, but have a wider risk effect when flaws exist. In contrast, software flaws can be fixed and updated/spread more rapidly then hardware flaws. How long was the gap between enthusiast plan makers to standardised specification for commercial use? HIPPA offers a bunch of guides (if i understand HIPPA 🤷♂️). How linnet is HIPPA compared to commercial plan requirements?
I'm very reluctant to put the word "engineering" after "software". There isn't the same level of agreement about how to do things in the software community as there is in the engineering community. We have competing language families, processes, methodologies, and even design patterns (the latter being a stab at something that starts to look like engineering). Engineering over-designs systems by a considerable factor to reduce the risk of failure. What's the equivalent in software, maybe building lots of defensive checks into the code? Still a pale imitation. On the other hand, a customer who came back to the engineering team saying that he wanted his bridge lengthened by 200m on its "next release" would be laughed out of the room, as would someone who took his car to a mechanic and asked for it to be fixed ("patched") while still traveling down the road.
-
Saw a comic strip the other day semi-joking about Aeroplanes being relatively safe Bridges being safe then software built voting system - 😭 Several bits come to mind, some obvious like physical access. But one that stands out the most is scale of access. Recent Phillips light bulk hack indicates this train of though. Breaking 1 bit of software potentially allows access to the whole thing. Tampering a plane or bridge to fail are more localised to the one occurrence. But "hack" a tesla, or digital polling station, and the spread risk is high. So yes, funny as a joke, but seriously, it is not so much that software engineering is more poorly implemented (ignoring the 90% of low code quality) then physical engineering disciplines, but have a wider risk effect when flaws exist. In contrast, software flaws can be fixed and updated/spread more rapidly then hardware flaws. How long was the gap between enthusiast plan makers to standardised specification for commercial use? HIPPA offers a bunch of guides (if i understand HIPPA 🤷♂️). How linnet is HIPPA compared to commercial plan requirements?
This one? xkcd: Voting Software[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
lopatir wrote:
when the app you're on crashes it just pisses you off.
That may be true for a lot of them; but sometimes an error may cause financial damage or endanger health.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
that's why I absolutely stay away from banking apps on my phone, touch screens weren't designed for folks like me with bent and fat fingers.
Do you accept the T&C ... [as in you click the wrong thing it's your fault]
No! damn, accidentally clickedYes, ...uninstall...no not:update...uninstall...uninstall...UNINSTALLyou POS ...finallyafter many otherwise intelligent sounding suggestions that achieved nothing the nice folks at Technet said the only solution was to low level format my hard disk then reinstall my signature. Sadly, this still didn't fix the issue!
-
Have you ever seen an (non-Boeing) aeroplane or bridge being built using the Agile methodology? :)
maze3 wrote:
but have a wider risk effect when flaws exist.
Like grounding an entire fleet of planes? Or recalling all cheeses from the supermarket due to contamination?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
ah yeah, I guess i was thinking more along the lines of external threat actors, rather then inherit design failings 🤣 my mind is now imagining an agile built plane. Developers: here, test this plane. Results: did not take off and crashed into a wall. Killed 8 people. Developers: Sorry about this, but could you details the issue a bit better, do you have some images of what the pilot was doing?
-
Saw a comic strip the other day semi-joking about Aeroplanes being relatively safe Bridges being safe then software built voting system - 😭 Several bits come to mind, some obvious like physical access. But one that stands out the most is scale of access. Recent Phillips light bulk hack indicates this train of though. Breaking 1 bit of software potentially allows access to the whole thing. Tampering a plane or bridge to fail are more localised to the one occurrence. But "hack" a tesla, or digital polling station, and the spread risk is high. So yes, funny as a joke, but seriously, it is not so much that software engineering is more poorly implemented (ignoring the 90% of low code quality) then physical engineering disciplines, but have a wider risk effect when flaws exist. In contrast, software flaws can be fixed and updated/spread more rapidly then hardware flaws. How long was the gap between enthusiast plan makers to standardised specification for commercial use? HIPPA offers a bunch of guides (if i understand HIPPA 🤷♂️). How linnet is HIPPA compared to commercial plan requirements?
maze3 wrote:
In contrast, software flaws can be fixed and updated/spread more rapidly then hardware flaws.
By the same token, newly introduced flaws or bugs are spread more rapidly to those trusting end users...especially mobile. :laugh: Confession...I once broke the auto-update feature for one of our products...not fun. Bugs happen. :)
"Go forth into the source" - Neal Morse
-
This one? xkcd: Voting Software[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Hey now, don't bury it _my_ desert.
-
Have you ever seen an (non-Boeing) aeroplane or bridge being built using the Agile methodology? :)
maze3 wrote:
but have a wider risk effect when flaws exist.
Like grounding an entire fleet of planes? Or recalling all cheeses from the supermarket due to contamination?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Eddy Vluggen wrote:
Have you ever seen an (non-Boeing) aeroplane or bridge being built using the Agile methodology?
Well said. Nothing in the real world that I'm aware of uses Agile except supposedly software development. I think that says something (either about my ignorance or the stupidity of Agile, I suspect the latter, not the former.)
Latest Articles:
Abusing Extension Methods, Null Continuation, and Null Coalescence Operators -
ah yeah, I guess i was thinking more along the lines of external threat actors, rather then inherit design failings 🤣 my mind is now imagining an agile built plane. Developers: here, test this plane. Results: did not take off and crashed into a wall. Killed 8 people. Developers: Sorry about this, but could you details the issue a bit better, do you have some images of what the pilot was doing?
maze3 wrote:
Developers: Sorry about this, but could you details the issue a bit better, do you have some images of what the pilot was doing?
Developers: It was a user error. Oh gee, that sounds familiar. :sigh:
Latest Articles:
Abusing Extension Methods, Null Continuation, and Null Coalescence Operators -
Have you ever seen an (non-Boeing) aeroplane or bridge being built using the Agile methodology? :)
maze3 wrote:
but have a wider risk effect when flaws exist.
Like grounding an entire fleet of planes? Or recalling all cheeses from the supermarket due to contamination?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
All manufacturing uses the agile methodology; they just don't call it agile, and everyone does the same thing every sprint. Software is a special case, though, because it's more like bespoke carpentry, where the whole process, from ideation to design to production, can be carried out by one person -- or for bigger things, like making pianos, three guys get a leg each. It's just a process for doing your daily work. Whether it's better or worse than other methods is purely a matter of taste -- for my tastes, it doesn't matter which method is followed (and I've done 'em all). Just get the work done. If the process becomes your work, you're not a developer, any more.
I wanna be a eunuchs developer! Pass me a bread knife!
-
All manufacturing uses the agile methodology; they just don't call it agile, and everyone does the same thing every sprint. Software is a special case, though, because it's more like bespoke carpentry, where the whole process, from ideation to design to production, can be carried out by one person -- or for bigger things, like making pianos, three guys get a leg each. It's just a process for doing your daily work. Whether it's better or worse than other methods is purely a matter of taste -- for my tastes, it doesn't matter which method is followed (and I've done 'em all). Just get the work done. If the process becomes your work, you're not a developer, any more.
I wanna be a eunuchs developer! Pass me a bread knife!
No, that's not agile; manufacturing has a clear and well-defined endproduct; there's no basement of a house while being undecided about the amount of stories, or the amount of stairs and elevators. The only stuff that's agile outside our own trade, is pharmacy; medication that doesn't work, but has reliable side-effects gets re-marketed to that side-effect as being the main thing.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
I'm very reluctant to put the word "engineering" after "software". There isn't the same level of agreement about how to do things in the software community as there is in the engineering community. We have competing language families, processes, methodologies, and even design patterns (the latter being a stab at something that starts to look like engineering). Engineering over-designs systems by a considerable factor to reduce the risk of failure. What's the equivalent in software, maybe building lots of defensive checks into the code? Still a pale imitation. On the other hand, a customer who came back to the engineering team saying that he wanted his bridge lengthened by 200m on its "next release" would be laughed out of the room, as would someone who took his car to a mechanic and asked for it to be fixed ("patched") while still traveling down the road.
Greg Utas wrote:
as would someone who took his car to a mechanic and asked for it to be fixed ("patched") while still traveling down the road.
Tesla?
Wrong is evil and must be defeated. - Jeff Ello
-
Saw a comic strip the other day semi-joking about Aeroplanes being relatively safe Bridges being safe then software built voting system - 😭 Several bits come to mind, some obvious like physical access. But one that stands out the most is scale of access. Recent Phillips light bulk hack indicates this train of though. Breaking 1 bit of software potentially allows access to the whole thing. Tampering a plane or bridge to fail are more localised to the one occurrence. But "hack" a tesla, or digital polling station, and the spread risk is high. So yes, funny as a joke, but seriously, it is not so much that software engineering is more poorly implemented (ignoring the 90% of low code quality) then physical engineering disciplines, but have a wider risk effect when flaws exist. In contrast, software flaws can be fixed and updated/spread more rapidly then hardware flaws. How long was the gap between enthusiast plan makers to standardised specification for commercial use? HIPPA offers a bunch of guides (if i understand HIPPA 🤷♂️). How linnet is HIPPA compared to commercial plan requirements?
Bridges collapse, planes crash, the little piece of string holding up my blinds broke. And so does my software contain a couple of bugs. The difference is that my software changes constantly, is on a tight budget, has no budget for R&D at all and has a strict deadline. Yet, my software works quite well. Until someone uses all kinds of power tools, external software and social hacking to make it break or get in. Trust me, if I had the physical equivalent of the tools hackers use to break software, I'd be able to break bridges and planes. And let's be honest, if you used a sledgehammer to wreck your neighbors house no one would blame the structural integrity of the house, yet when hackers do the same to software, it's the software that's at fault. That said, a lot of bad programmers and crap software exist and sometimes I'm ashamed of the industry :(
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Saw a comic strip the other day semi-joking about Aeroplanes being relatively safe Bridges being safe then software built voting system - 😭 Several bits come to mind, some obvious like physical access. But one that stands out the most is scale of access. Recent Phillips light bulk hack indicates this train of though. Breaking 1 bit of software potentially allows access to the whole thing. Tampering a plane or bridge to fail are more localised to the one occurrence. But "hack" a tesla, or digital polling station, and the spread risk is high. So yes, funny as a joke, but seriously, it is not so much that software engineering is more poorly implemented (ignoring the 90% of low code quality) then physical engineering disciplines, but have a wider risk effect when flaws exist. In contrast, software flaws can be fixed and updated/spread more rapidly then hardware flaws. How long was the gap between enthusiast plan makers to standardised specification for commercial use? HIPPA offers a bunch of guides (if i understand HIPPA 🤷♂️). How linnet is HIPPA compared to commercial plan requirements?
A problem I face all the time on my own workplace is that software is considered to be malleable. Well, it technically is, but to achieve safety (or even something resembling quality), the mindset has to shift towards an engineering "think first" aproach. My product managers don't want to. They prefer a more artisinal aproach: telling roughly what they want, seeing the result, having things change, seeing the result of that and so on. I suppose, the main issue with software is this aproach working at first. Sure, it breaks down later (let's say because the main engine of what I'm building isn't capable of something that TOTALLY HAS TO BE ADDED a month or two later) but at first, it's malleable and the cost of this nonsense is all-too-easy to dump on the programmer because hey, I'm the one introducing all the bugs, aren't I? Building a bridge or a plane, it's kinda obvious that things have to be thought through in advance. But building software, there's no immediate need to do anything in advance. And as people are, they tend to ignore everything that comes tomorow for the sake of today.
-
maze3 wrote:
Developers: Sorry about this, but could you details the issue a bit better, do you have some images of what the pilot was doing?
Developers: It was a user error. Oh gee, that sounds familiar. :sigh:
Latest Articles:
Abusing Extension Methods, Null Continuation, and Null Coalescence OperatorsAnd then factor in support when you have a, let's call it suboptimal, product. There the 'it's not my/our fault' really gets to shine. EG:I could not use a slightly advanced feature on an internet connection (open a port to the outside) and documented it had to be a problem ISP side. They kept repeating the same inane and refuted advice mixed with telling me what they couldn't do, never said a word to what they could do, until someone (bless him) decided my cablemodem was a bit old. They sent a replacement and stuff worked. Don't want to know what would have happened if my modem had been newish. So I should be happy. And I am. But look a bit closer and you will see that their actual assistance was zilk, without my own knowledge I would have been helpless, and that they probably easily avoided learning anything from this small incident, the more so since not closing an issue is regarded as bad perfomance. The guy who helped my out probably thought he did a good deed and left it there. Upshot: support is (another) step down from product quality and even more likely to suffer under the letal mix of under pressure psychology and management. Quite comparable to boeing saying they will fix the software when they should fix the plane, and then having more critical (software) flaws discovered. Software to the rescue! Then support gets kicked up the ladder (to communication and higher) who are obviously completely unsuited for this job, but cannot admit it. There are real disasters waiting to happen. But it won't be my fault (/s. I regard this sentence as the first law of psychology so I keep using it in sarcastic mode). I've just put on Industrial Disease (Dire Straits). Good for the mood.
-
No, that's not agile; manufacturing has a clear and well-defined endproduct; there's no basement of a house while being undecided about the amount of stories, or the amount of stairs and elevators. The only stuff that's agile outside our own trade, is pharmacy; medication that doesn't work, but has reliable side-effects gets re-marketed to that side-effect as being the main thing.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Eddy Vluggen wrote:
medication that doesn't work, but has reliable side-effects gets re-marketed to that side-effect as being the main thing.
I'll have to assume that you have more knowledge than I about little blue pills.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Greg Utas wrote:
as would someone who took his car to a mechanic and asked for it to be fixed ("patched") while still traveling down the road.
Tesla?
Wrong is evil and must be defeated. - Jeff Ello
