3 ms·

I have some engineering background and you only have engineers in stable predictable fields. You can predict quite accurately the failure load of a bridge trus

by VLM 10y ago

I have some engineering background and you only have engineers in stable predictable fields. You can predict quite accurately the failure load of a bridge truss or a transistor and its easily testable and the whole process can be simulated and verified top to bottom. My guess is the wedge to bring in engineering would be network operations, classic operations (not devops which just means we're gonna pencil whip the ops responsibilities). Maybe large data center operations (thermal, electrical loads, UPS, etc) is amenable to engineering workflows. Software is simply too unpredictable. Both in development and operation. Software is still in the "greeks and amber and rabbit fur experiments" stage of electrical engineering.

mjevans 10y ago
The ethical and competency attributes are still relevant. Particularly with respect to actual engineering (architecture of the overall solution) aspects of logic systems development and deployment.
- slg 10y ago
  I think one of the main problems with ethics is the abstract nature of software and development. Let's say you create an encryption algorithm. That algorithm can be used by terrorists and pedophiles or it can be used by banks and civil disobedients. Or let's say you create an encryption breaking algorithm. That algorithm can be used by law enforcement and the judicial system or it can be used by identity thieves and oppressive governments. Are you as the developer responsible for all those uses? It is hard enough to know how your employer will use your code in the future, but it would be literally impossible for any open source software.
  - marichards 10y ago
    This kind of argument applies to anything, even paper. Encryption is just a tool. A pipe can be used to hide and carry water, it can also be tampered with to poison someone or conceal explosives.
    - slg 10y ago
      Which is why we don't force an ethical code on those producing pipes. We instead decided to regulate their finished product. However if someone on HN suggests regulating encryption, they aren't met with the most open arms.
woud420 10y ago
Just a note, looking at the way most companies I've been involved with handle RF testing, it still feels like some electrical engineering is at a premature stage also. Testing a transistor is the equivalent of testing an if statement. Both are trivial. The difficulty comes from testing multiple of these components acting in sync. Let's be honest, it's sometimes not worth the return on investment to test outside of your requirements. If software has potential to injure someone, I would hope that it's been tested to similar specifications that hardware is tested on.
devoply 10y ago
You can make software a predictive profession, by adding an order of magnitude of cost to every software development effort. 10x. It's not that it can't be done. It's the market is not suitable for that sort of development. It's a management problem, not a software engineer problem. There are a huge number of combinations of various statements that have to be iterated over meticulously. If you want to write tests for each and every one of these conditions, it's going to eat a ton of time to do just that and hence add tons of cost to your project. Developers use intuition when dealing with logic, and they make mistakes or don't understand all the possibilities that could occur... because the brain is limited like that. You can't make them not do that. You can just test for it after the fact and fix problems that are identified, that potentially adds huge cost if you are looking to make it fully predictable. Lots of testing happens in production systems. Especially in open source software. Or during implementation of some library. Those are identified and fixed when identified. To do that within a single effort will add huge cost to the projects.
- nickpsecurity 10y ago
  "You can make software a predictive profession, by adding an order of magnitude of cost to every software development effort. 10x. " This is a recurting myth. The field of high-assurance software delivers it on a regular basis in regulated markets. They built tools and reusable modules that drove costs down a lot. Still high cost vs throwing crap together. So, methods were invented far as the 80's to get most of those benefits on the chesp. Cleanroom methodology got very low defects with cost modifier ranging from cheaper to 20 or so percent more extra. That debugging & hard-to-change codd were greatly reduced offset upfront cost. LOCK secure kernel reported about 38% extra cost with full, formal verification & leak prevention. Altran/Praxis does it today for their clients with a mix of Z, Ada, and SPARK for claimed 50% premium. None of these are "10x" higher. Maxed out at 1.5x for most. Market can bear that. Only proven weakness of highly-assured development is time to market. Features do take longer to build if verified thoroughly. Medium-assurance like Cleanroom has some slowdown but acceptable. Less debugging and breakage by extensions offsets that, too.
  - michaelt 10y ago
serge2k 10y ago
> Software is simply too unpredictable. Both in development and operation You could make it much more predictable if the developer had the legal authority and obligation to sign off on all software. Fuck you I'm not putting my name on that, if you fire me I'll raise a stink about you trying to coerce me into putting my name on something unsafe. This really isn't needed in most cases though.
edejong 10y ago
Software is unpredictable because there is little demand for predictability. As it is a trade-off, predictability requires experience. Inexperienced application of methods to enhance predictability is expensive. Speaking from experience: - Isolate state in modules (micro-services) - Focus on systems language first, external behaviour second, implementation details last. - Design systems to fail and fail fast. - Do not adhere to Postel's law. Be strict in what your systems accept. This forces the systems designer to create a language which is extensible. And general advice for teams: - Consistency is the most important factor in success. Choose rarely and choose wisely your: languages / eco-systems / OSes / cloud services / frameworks. Change based on requirements, not HN popularity.

by VLM 10y ago

mjevans 10y ago

The ethical and competency attributes are still relevant. Particularly with respect to actual engineering (architecture of the overall solution) aspects of logic systems development and deployment.

slg 10y ago
I think one of the main problems with ethics is the abstract nature of software and development. Let's say you create an encryption algorithm. That algorithm can be used by terrorists and pedophiles or it can be used by banks and civil disobedients. Or let's say you create an encryption breaking algorithm. That algorithm can be used by law enforcement and the judicial system or it can be used by identity thieves and oppressive governments. Are you as the developer responsible for all those uses? It is hard enough to know how your employer will use your code in the future, but it would be literally impossible for any open source software.
- marichards 10y ago
  This kind of argument applies to anything, even paper. Encryption is just a tool. A pipe can be used to hide and carry water, it can also be tampered with to poison someone or conceal explosives.
  - slg 10y ago
    Which is why we don't force an ethical code on those producing pipes. We instead decided to regulate their finished product. However if someone on HN suggests regulating encryption, they aren't met with the most open arms.

woud420 10y ago

Just a note, looking at the way most companies I've been involved with handle RF testing, it still feels like some electrical engineering is at a premature stage also. Testing a transistor is the equivalent of testing an if statement. Both are trivial. The difficulty comes from testing multiple of these components acting in sync. Let's be honest, it's sometimes not worth the return on investment to test outside of your requirements. If software has potential to injure someone, I would hope that it's been tested to similar specifications that hardware is tested on.

devoply 10y ago

You can make software a predictive profession, by adding an order of magnitude of cost to every software development effort. 10x. It's not that it can't be done. It's the market is not suitable for that sort of development. It's a management problem, not a software engineer problem. There are a huge number of combinations of various statements that have to be iterated over meticulously. If you want to write tests for each and every one of these conditions, it's going to eat a ton of time to do just that and hence add tons of cost to your project. Developers use intuition when dealing with logic, and they make mistakes or don't understand all the possibilities that could occur... because the brain is limited like that. You can't make them not do that. You can just test for it after the fact and fix problems that are identified, that potentially adds huge cost if you are looking to make it fully predictable. Lots of testing happens in production systems. Especially in open source software. Or during implementation of some library. Those are identified and fixed when identified. To do that within a single effort will add huge cost to the projects.

nickpsecurity 10y ago
"You can make software a predictive profession, by adding an order of magnitude of cost to every software development effort. 10x. " This is a recurting myth. The field of high-assurance software delivers it on a regular basis in regulated markets. They built tools and reusable modules that drove costs down a lot. Still high cost vs throwing crap together. So, methods were invented far as the 80's to get most of those benefits on the chesp. Cleanroom methodology got very low defects with cost modifier ranging from cheaper to 20 or so percent more extra. That debugging & hard-to-change codd were greatly reduced offset upfront cost. LOCK secure kernel reported about 38% extra cost with full, formal verification & leak prevention. Altran/Praxis does it today for their clients with a mix of Z, Ada, and SPARK for claimed 50% premium. None of these are "10x" higher. Maxed out at 1.5x for most. Market can bear that. Only proven weakness of highly-assured development is time to market. Features do take longer to build if verified thoroughly. Medium-assurance like Cleanroom has some slowdown but acceptable. Less debugging and breakage by extensions offsets that, too.
- michaelt 10y ago

serge2k 10y ago

> Software is simply too unpredictable. Both in development and operation You could make it much more predictable if the developer had the legal authority and obligation to sign off on all software. Fuck you I'm not putting my name on that, if you fire me I'll raise a stink about you trying to coerce me into putting my name on something unsafe. This really isn't needed in most cases though.

edejong 10y ago

Software is unpredictable because there is little demand for predictability. As it is a trade-off, predictability requires experience. Inexperienced application of methods to enhance predictability is expensive. Speaking from experience: - Isolate state in modules (micro-services) - Focus on systems language first, external behaviour second, implementation details last. - Design systems to fail and fail fast. - Do not adhere to Postel's law. Be strict in what your systems accept. This forces the systems designer to create a language which is extensible. And general advice for teams: - Consistency is the most important factor in success. Choose rarely and choose wisely your: languages / eco-systems / OSes / cloud services / frameworks. Change based on requirements, not HN popularity.