10 ms·

Software is currently in a strange place legislatively, in the 18th century Civil Engineering exploded (sometimes literally) and the number of disasters went up

Software is currently in a strange place legislatively, in the 18th century Civil Engineering exploded (sometimes literally) and the number of disasters went up in radically (for an interesting case https://en.wikipedia.org/wiki/Tay_Bridge_disaster https://en.wikipedia.org/wiki/Tay_Bridge_disaster), over time professional standards bodies grew alongside the maturing industry to both ensure that people working in the industry where adequately trained and adequately protected from external factors (people pushing them to do things cheaply, skimp on designs etc). Given that we've handed a large part of the running of the modern world over to computers, software and the people who write that software I think at some point we need to start looking at a similar system, now the usual argument to this is "We don't want regulation" or "It's not my code, it's other peoples" but that doesn't alter the reality that this isn't going to get better until the way the industry is run changes, it's not a software issue, better tooling won't save us (it might help though) and there is no perfect outcome. EDIT: It's worth noting that if as an industry we don't work with our customers on this stuff and reach an accord that fits everyone eventually one will be imposed on us from outside, Software Engineering doesn't exist in isolation, other fields of Engineering are covered already.

jdietrich 10y ago
We need formal codes of practice, we need good institutions, but we also need a cultural change. We no longer have the luxury of saying "oh, it's just a CRUD app, it doesn't matter if things go wrong". Software has become too important, it has become too deeply intertwined in our daily lives. Errors and leaks from trivial little apps can have life-changing consequences for users. If your software handles personally identifying data, there's a non-zero chance that you could ruin someone's life through negligence. Legal case management software might be an obvious example, but it's the tip of a very big iceberg. If you have several million users, one-in-a-million edge cases are going to happen constantly. Weird things happen at scale. We need to treat every Android permission and every Facebook API call as a potential matter of life or death. We need the personal courage and the support of our peers to say "no, I will not implement that feature", "no, I will not store that user data", "no, I will not transmit that in plaintext", "no, I will not commit that to production without unit testing". https://en.wikipedia.org/wiki/Iron_Ring https://en.wikipedia.org/wiki/Iron_Ring
- tener 10y ago
  Don't put the blame on the developers. Too frequently they are put under huge pressure and cannot say "no" to their managers. There are people which are responsible for delivery, testing and they are paid way more than the average developer. Unlike in engineering, with software you can - and indeed should - test it before deployment in thousands of ways. Finally there is also a receiving party that should ensure they are not accepting broken software. They have responsibility too.
  - CodeMage 10y ago
    I would amend that to "don't put the blame solely on the developers". I've seen way too many developers whose mentality is "ship it, it seems good enough, we'll fix any bugs as we go".
    - tener 10y ago
      If the company culture is supporting this attitude, then sure - you will have developers saying that. But it isn't the developers that create that culture. This is something the management is responsible for.
      - mseebach 10y ago
        Exactly. This is why bosses make the big bucks. Developers are just code-machines and they will perform poorly or well entirely dependent on their external environment and culture created by their management. (Oh, it's a one way thing, you say? Bosses are to blame for failure, but devs get credit for successes? Head I win, tails you lose?)
      - FullMtlAlcoholc 10y ago
        The fact that a person acted pursuant to order of of a superior does not relieve him from responsibility. This can be a difficult decision to make in these circumstances, but I just couldn't ship buggy code that may be responsible for someone being unfairly jailed. That's why I try to always document as much as possible in the workplace.
pjungwir 10y ago
We already have a taste of these rules and regulations, for example HIPAA, PCI, and FIPS-140. I'm not saying I disagree with you, but keep in mind that those are all considered quite burdensome, and it's hard to see how that could be different. Also FIPS-140 is a good example of a standard that names specific technologies and so is doomed to lag behind the state of the art. Just be careful what you wish for! But as you say, it seems inevitable for more rules to be imposed eventually, one way or another, so perhaps we should think about how we might write better ones.
- djsumdog 10y ago
  There are also terrible project management standards like CMMI, which a lot of agencies try to adopt to get government grants. Standards that were designed to increase quality by clearly defining the work, ended up doing neither. The trouble with comparing it to Civil Engineering is you have a bridge. The bridge has plans and you can have other engineers and physicists look at it, do the maths, and figure out if it is sound. You can have independent auditing, and you have do, because if a bridge fails, people die. In software, we don't often feel that same burden. Also, unlike the bridge, software doesn't wear out over time. It may increase load, to the point where even with more hardware it won't scale. It may also become difficult to maintain due to old/unmaintained libraries, older language that are difficult to find developers for, or just that it was badly written and bandages together -- all of which is what we often called "Technical Debt". We do have life critical software, such as the software in a pacemaker, in your cars ECU, in airplane navigation and control systems. The industry holds themselves to a high standard, and some of those companies may do independent auditing (if for liability than anything else). But even then, we see things get through as there are talks at hackcons at hacking things like cars, airplanes and biomedical devices. In this article, we have a piece of software that seems like it's just data entry software. From the limited amount of information, it seems to have been poorly designed and buggy. If this was for the inventory at a retailer, yea who cares. Some grocery stories or gas station chains now lose a ton of time and money because they made a bad decision. If prices go up because of that, you just go to another one, or they just eat those costs. When this deals with government information about people, you get into a whole different area. Another case that's similar: Novapay in New Zealand. A terribly designed education payroll system caused thousands of teachers to not be paid for months. That affects peoples' lives.
0xdeadbeefbabe 10y ago
Can one of the standards be that if the software costs money it should perform proportionally better than a free alternative?
- briandear 10y ago
  What difference does that make?
  - 0xdeadbeefbabe 10y ago
    Well usually if you pay more for something like a manufactured good or art work you get more value, but the rule for software seems to be the more you pay for it the less value you get.
pmontra 10y ago
There are cases where this approach would be very welcome. However it probably won't solve the problem of "a cumbersome user interface was causing the time taken to update a record to jump from around one minute to as much as 30 minutes per entry." That's bad design with maybe the collaboration of the customer who didn't understand the problem or pushed/spent enough to fix it. Not different from building a bridge too narrow to make two cars pass at the same time: perfectly safe but not functional enough. Engineer's fault, customer's fault, both? In the case of this software who's going to be sued, the developer or the customer? The customer by the people in jail and maybe the developer by the customer? However, let's also try to compare the complexity of that software system with the complexity of a bridge. What would be more complex, that Tay Bridge or California's Odyssey? I bet on the latter and I assume that it would cost much more money and time to properly build and test software systems. It's almost only manpower, compared to concrete, steel and wood, but the costs could go up by one order of magnitude compared to what they are now. If this approach gets mandated it would be a big slow down for every industry needing custom software. It also means we'll only need 1/10th of customers to keep our shops open, the 10% with more money. Goodbye to the small ones. There will be the equivalent of a construction site manager, but good luck with the bugs that become apparent or are introduced after years of changes to the first accepted delivery of the project. Bridges are much more static than software.
gravypod 10y ago
> professional standards bodies grew alongside the maturing industry > ensure that people working in the industry where adequately trained and adequately protected from external factors > software and the people who write that software I think at some point we need to start looking at a similar system Who this gets implemented I'll quit and become a welder or something else that's outdoors and filled with less insane propositions. The BS and stupidity that gets setup by these standards organizations is crazy. I know many people who are PEs who can testify that all of this is completely useless. It's often said by people who give these certifications that you shouldn't go into industry before getting these. That's acceptable until you hear why: you'll forget a lot of stuff that is unused in industry but used in these exams. This is horrible design at it's best. "Engineering Standardization" in this form is good for a few things: 1. Driving up the cost by keeping perfectly good engineers out of the field and making the industry talent starved. 2. Creating a corrupt standardization organization that makes it so their "group" can get certificates while others cant. 3. A reduction to the speed of new ideas entering the field. Less people allowed in all of which are brainwashed into "THIS IS THE WAY, YOU WILL OBEY" 4. A lack of care for checking work; "They're a professional engineer, you know better then me" 5. Preserving irrelevant information that isn't at all related to the task at hand (A+, I'm looking at you) I think the real solution is for universities to actually teach people how to program, about software architecture, about software engineering, about maintenance, and less about things that you won't necessarily be doing. I'm in senior level classes at college and I find that most of my peers have problem "doing programming" and I know people in the EE track who have problems "doing electronics". These aren't stupid people, they are just lacking instruction needed to succeed in the field. Another solution is to have a simple standard: All life endangering software must either be a) formally proven by the programmers and checked by a mathematician or b) have unit testing for every possible case of every testable portion of the code. If both of these are done then it will save far more lives then useless standards that will be actively ignored. These two standards are already where our field is naturally going and embracing that will only yield higher quality software for everyone. Using stupid standards documents that specify things like "functions can only be 80 chars wide and 100 lines long" or "no memory allocation after startup" It also avoids forming unnatural accreditation bodies that are harmful to the industry. Edit: I'd also be perfectly fine with something like UL for software.
dispose13432 10y ago
The threat model of code is different than that of bridges, and legislation won't help. Civil engineers have to make sure that bridges won't naturally collapse. Software "engineers" have to ensure that no one will break their code, from the privacy and anonymity of their house, with millions of dollars in payoffs. If bridges held millions of dollars and would be accessible from around the world, they would be breaking all the time also.
- mdpopescu 10y ago
  Agreed. "Programming Satan's Computer" is a good paper on the subject of code running under constant attack.
- nine_k 10y ago
  Compare it to automotive engineering. Cars are designed with an assumption that they will be sometimes mishandled, tipped over, crashed into things, run into bodies of water, set on fire, etc. In these circumstances cars should behave as to best preserve humans' safety, both inside (passengers) and outside (pedestrians). This leads to some serious design decisions on deeper level, e.g. making the engine go under the rest of the car on a frontal collision, adding a structural cage around the passenger compartment, etc. Deeply defensive programming methodologies also exist, from using safer languages and formally proven algorithms to pen-testing the completed setup. Their adoption just costs effort and time, that is, money.
  - dispose13432 10y ago
    >Cars are designed with an assumption that they will be sometimes mishandled But not maliciously. If you run your car at another, the other car will break. I would compare it to lock-making. Despite thousands of years of lock-making, they _still_ get broken, and there's nothing to be done about it. >Deeply defensive programming methodologies also exist, from using safer languages and formally proven algorithms to pen-testing the completed setup. Their adoption just costs effort and time, that is, money. It's not just money. It's paperwork, bureaucracy, and ultimately not effective. Practically, the only way to ensure safety is to take down the internet.
jancsika 10y ago
Position one: implement professional-training program and whistleblower-protections for employees of the out-of-state companies writing the proprietary software for CA court system Position two: require court system software to be open source You might reply that open source is no panacea, and that's true. But the vulnerabilities in current software are wholly different than the ones in civil (physical) engineering-- both your imagined "professional grade" proprietary court app and my imagined open source court app will have critical vulnerabilities. The question is what happens when they are found. I'd like to read a blog entry complete with screen captures by a security expert who is running the exact same software, posted after the exploit has been responsibly reported and addressed. I do not want to read an opaque statement from a company blaming its users, and I don't see how even a set of strong, effective software engineering guidelines is going to get you anything else in this case. Edit: I said "vulnerabilities", but the logic applies equally to usability issues, data corruption, etc.

jdietrich 10y ago

We need formal codes of practice, we need good institutions, but we also need a cultural change. We no longer have the luxury of saying "oh, it's just a CRUD app, it doesn't matter if things go wrong". Software has become too important, it has become too deeply intertwined in our daily lives. Errors and leaks from trivial little apps can have life-changing consequences for users. If your software handles personally identifying data, there's a non-zero chance that you could ruin someone's life through negligence. Legal case management software might be an obvious example, but it's the tip of a very big iceberg. If you have several million users, one-in-a-million edge cases are going to happen constantly. Weird things happen at scale. We need to treat every Android permission and every Facebook API call as a potential matter of life or death. We need the personal courage and the support of our peers to say "no, I will not implement that feature", "no, I will not store that user data", "no, I will not transmit that in plaintext", "no, I will not commit that to production without unit testing". https://en.wikipedia.org/wiki/Iron_Ring https://en.wikipedia.org/wiki/Iron_Ring

tener 10y ago
Don't put the blame on the developers. Too frequently they are put under huge pressure and cannot say "no" to their managers. There are people which are responsible for delivery, testing and they are paid way more than the average developer. Unlike in engineering, with software you can - and indeed should - test it before deployment in thousands of ways. Finally there is also a receiving party that should ensure they are not accepting broken software. They have responsibility too.
- CodeMage 10y ago
  I would amend that to "don't put the blame solely on the developers". I've seen way too many developers whose mentality is "ship it, it seems good enough, we'll fix any bugs as we go".
  - tener 10y ago
    If the company culture is supporting this attitude, then sure - you will have developers saying that. But it isn't the developers that create that culture. This is something the management is responsible for.
    - mseebach 10y ago
      Exactly. This is why bosses make the big bucks. Developers are just code-machines and they will perform poorly or well entirely dependent on their external environment and culture created by their management. (Oh, it's a one way thing, you say? Bosses are to blame for failure, but devs get credit for successes? Head I win, tails you lose?)
    - FullMtlAlcoholc 10y ago
      The fact that a person acted pursuant to order of of a superior does not relieve him from responsibility. This can be a difficult decision to make in these circumstances, but I just couldn't ship buggy code that may be responsible for someone being unfairly jailed. That's why I try to always document as much as possible in the workplace.

pjungwir 10y ago

We already have a taste of these rules and regulations, for example HIPAA, PCI, and FIPS-140. I'm not saying I disagree with you, but keep in mind that those are all considered quite burdensome, and it's hard to see how that could be different. Also FIPS-140 is a good example of a standard that names specific technologies and so is doomed to lag behind the state of the art. Just be careful what you wish for! But as you say, it seems inevitable for more rules to be imposed eventually, one way or another, so perhaps we should think about how we might write better ones.

djsumdog 10y ago
There are also terrible project management standards like CMMI, which a lot of agencies try to adopt to get government grants. Standards that were designed to increase quality by clearly defining the work, ended up doing neither. The trouble with comparing it to Civil Engineering is you have a bridge. The bridge has plans and you can have other engineers and physicists look at it, do the maths, and figure out if it is sound. You can have independent auditing, and you have do, because if a bridge fails, people die. In software, we don't often feel that same burden. Also, unlike the bridge, software doesn't wear out over time. It may increase load, to the point where even with more hardware it won't scale. It may also become difficult to maintain due to old/unmaintained libraries, older language that are difficult to find developers for, or just that it was badly written and bandages together -- all of which is what we often called "Technical Debt". We do have life critical software, such as the software in a pacemaker, in your cars ECU, in airplane navigation and control systems. The industry holds themselves to a high standard, and some of those companies may do independent auditing (if for liability than anything else). But even then, we see things get through as there are talks at hackcons at hacking things like cars, airplanes and biomedical devices. In this article, we have a piece of software that seems like it's just data entry software. From the limited amount of information, it seems to have been poorly designed and buggy. If this was for the inventory at a retailer, yea who cares. Some grocery stories or gas station chains now lose a ton of time and money because they made a bad decision. If prices go up because of that, you just go to another one, or they just eat those costs. When this deals with government information about people, you get into a whole different area. Another case that's similar: Novapay in New Zealand. A terribly designed education payroll system caused thousands of teachers to not be paid for months. That affects peoples' lives.

0xdeadbeefbabe 10y ago

Can one of the standards be that if the software costs money it should perform proportionally better than a free alternative?

briandear 10y ago
What difference does that make?
- 0xdeadbeefbabe 10y ago
  Well usually if you pay more for something like a manufactured good or art work you get more value, but the rule for software seems to be the more you pay for it the less value you get.

pmontra 10y ago

There are cases where this approach would be very welcome. However it probably won't solve the problem of "a cumbersome user interface was causing the time taken to update a record to jump from around one minute to as much as 30 minutes per entry." That's bad design with maybe the collaboration of the customer who didn't understand the problem or pushed/spent enough to fix it. Not different from building a bridge too narrow to make two cars pass at the same time: perfectly safe but not functional enough. Engineer's fault, customer's fault, both? In the case of this software who's going to be sued, the developer or the customer? The customer by the people in jail and maybe the developer by the customer? However, let's also try to compare the complexity of that software system with the complexity of a bridge. What would be more complex, that Tay Bridge or California's Odyssey? I bet on the latter and I assume that it would cost much more money and time to properly build and test software systems. It's almost only manpower, compared to concrete, steel and wood, but the costs could go up by one order of magnitude compared to what they are now. If this approach gets mandated it would be a big slow down for every industry needing custom software. It also means we'll only need 1/10th of customers to keep our shops open, the 10% with more money. Goodbye to the small ones. There will be the equivalent of a construction site manager, but good luck with the bugs that become apparent or are introduced after years of changes to the first accepted delivery of the project. Bridges are much more static than software.

gravypod 10y ago

> professional standards bodies grew alongside the maturing industry > ensure that people working in the industry where adequately trained and adequately protected from external factors > software and the people who write that software I think at some point we need to start looking at a similar system Who this gets implemented I'll quit and become a welder or something else that's outdoors and filled with less insane propositions. The BS and stupidity that gets setup by these standards organizations is crazy. I know many people who are PEs who can testify that all of this is completely useless. It's often said by people who give these certifications that you shouldn't go into industry before getting these. That's acceptable until you hear why: you'll forget a lot of stuff that is unused in industry but used in these exams. This is horrible design at it's best. "Engineering Standardization" in this form is good for a few things: 1. Driving up the cost by keeping perfectly good engineers out of the field and making the industry talent starved. 2. Creating a corrupt standardization organization that makes it so their "group" can get certificates while others cant. 3. A reduction to the speed of new ideas entering the field. Less people allowed in all of which are brainwashed into "THIS IS THE WAY, YOU WILL OBEY" 4. A lack of care for checking work; "They're a professional engineer, you know better then me" 5. Preserving irrelevant information that isn't at all related to the task at hand (A+, I'm looking at you) I think the real solution is for universities to actually teach people how to program, about software architecture, about software engineering, about maintenance, and less about things that you won't necessarily be doing. I'm in senior level classes at college and I find that most of my peers have problem "doing programming" and I know people in the EE track who have problems "doing electronics". These aren't stupid people, they are just lacking instruction needed to succeed in the field. Another solution is to have a simple standard: All life endangering software must either be a) formally proven by the programmers and checked by a mathematician or b) have unit testing for every possible case of every testable portion of the code. If both of these are done then it will save far more lives then useless standards that will be actively ignored. These two standards are already where our field is naturally going and embracing that will only yield higher quality software for everyone. Using stupid standards documents that specify things like "functions can only be 80 chars wide and 100 lines long" or "no memory allocation after startup" It also avoids forming unnatural accreditation bodies that are harmful to the industry. Edit: I'd also be perfectly fine with something like UL for software.

dispose13432 10y ago

The threat model of code is different than that of bridges, and legislation won't help. Civil engineers have to make sure that bridges won't naturally collapse. Software "engineers" have to ensure that no one will break their code, from the privacy and anonymity of their house, with millions of dollars in payoffs. If bridges held millions of dollars and would be accessible from around the world, they would be breaking all the time also.

mdpopescu 10y ago
Agreed. "Programming Satan's Computer" is a good paper on the subject of code running under constant attack.
nine_k 10y ago
Compare it to automotive engineering. Cars are designed with an assumption that they will be sometimes mishandled, tipped over, crashed into things, run into bodies of water, set on fire, etc. In these circumstances cars should behave as to best preserve humans' safety, both inside (passengers) and outside (pedestrians). This leads to some serious design decisions on deeper level, e.g. making the engine go under the rest of the car on a frontal collision, adding a structural cage around the passenger compartment, etc. Deeply defensive programming methodologies also exist, from using safer languages and formally proven algorithms to pen-testing the completed setup. Their adoption just costs effort and time, that is, money.
- dispose13432 10y ago
  >Cars are designed with an assumption that they will be sometimes mishandled But not maliciously. If you run your car at another, the other car will break. I would compare it to lock-making. Despite thousands of years of lock-making, they _still_ get broken, and there's nothing to be done about it. >Deeply defensive programming methodologies also exist, from using safer languages and formally proven algorithms to pen-testing the completed setup. Their adoption just costs effort and time, that is, money. It's not just money. It's paperwork, bureaucracy, and ultimately not effective. Practically, the only way to ensure safety is to take down the internet.

jancsika 10y ago

Position one: implement professional-training program and whistleblower-protections for employees of the out-of-state companies writing the proprietary software for CA court system Position two: require court system software to be open source You might reply that open source is no panacea, and that's true. But the vulnerabilities in current software are wholly different than the ones in civil (physical) engineering-- both your imagined "professional grade" proprietary court app and my imagined open source court app will have critical vulnerabilities. The question is what happens when they are found. I'd like to read a blog entry complete with screen captures by a security expert who is running the exact same software, posted after the exploit has been responsibly reported and addressed. I do not want to read an opaque statement from a company blaming its users, and I don't see how even a set of strong, effective software engineering guidelines is going to get you anything else in this case. Edit: I said "vulnerabilities", but the logic applies equally to usability issues, data corruption, etc.