4 ms·

> Subject engineers to licensure That'd be great. It can also finally define a standard for things like clean code, development cycles and and design patterns.

> Subject engineers to licensure That'd be great. It can also finally define a standard for things like clean code, development cycles and and design patterns. Companies keep claiming to promote these things but it seems to be just a lot of equivocations.

robocat 3y ago
Because licensing is working so well in other disciplines? Magic fairy dust! Look at some civil engineering disasters: licensing doesn't prevent disasters.
- swiftcoder 3y ago
  > Look at some civil engineering disasters: licensing doesn't prevent disasters. I'd suggest that you are judging the effectiveness on the wrong criteria here. It's impossible to foresee all distasters - the goal is to enact mechanisms to mitigate the human cost of distasters, and even more importantly, prevent the second and third occurrences of the same distaster... (which we seem decently good at)
  - robocat 3y ago
    Licensing doesn't prevent similar disasters from happening. Licensing is simply too low-level to prevent problems. Licensing is a mechanism to scapegoat individual engineers. It doesn't fix issues with systems. And the penalty of losing a license is simply too cheap compared against the cost of major accidents. Engineering projects are usually performed by businesses, often across jurisdictional boundaries. Licensing is usually a monopoly within a jurisdiction. Avoiding accidents requires solutions at the level of a business activity: and it needs to cover all the aspects of the activity (not just the coalface of engineering, but the management and sales and every other aspect that can affect safety). If software engineering requires licenses then open source cannot be used. Good luck starting from scratch and introducing other risks of proprietary solutions! An example: a Lambourghini tractor has a fault in the steering software that causes the tractor to overturn and kills a farmer in Nabraska. How do you expect software engineering licensing to prevent that?
jpc0 3y ago
> clean code, development cycles and and design patterns We can't even agree that these things are in fact good ideas. Singleton is a design pattern, generally considered a bad one but it has important uses when used correctly. Clean code is good but only when done the correct amount, when done in a zealous manner just slows down development and adds extra overhead which will again cause mistakes. If anything I feel design by contract will become more of a standard, look at the JPL recommendations, they don't explicitly call it design by contract but it's build into the spec. Not enough "software engineers" even know what invariants need to hold, what preconditions need to be true and what postconditions need to be in place. Don't believe me, look for the equivalent of: try { // some code } catch(...) { // Handle all these errors we didnt know about and handle explicitly } In almost any codebase and it will be there.

robocat 3y ago

Because licensing is working so well in other disciplines? Magic fairy dust! Look at some civil engineering disasters: licensing doesn't prevent disasters.

swiftcoder 3y ago
> Look at some civil engineering disasters: licensing doesn't prevent disasters. I'd suggest that you are judging the effectiveness on the wrong criteria here. It's impossible to foresee all distasters - the goal is to enact mechanisms to mitigate the human cost of distasters, and even more importantly, prevent the second and third occurrences of the same distaster... (which we seem decently good at)
- robocat 3y ago
  Licensing doesn't prevent similar disasters from happening. Licensing is simply too low-level to prevent problems. Licensing is a mechanism to scapegoat individual engineers. It doesn't fix issues with systems. And the penalty of losing a license is simply too cheap compared against the cost of major accidents. Engineering projects are usually performed by businesses, often across jurisdictional boundaries. Licensing is usually a monopoly within a jurisdiction. Avoiding accidents requires solutions at the level of a business activity: and it needs to cover all the aspects of the activity (not just the coalface of engineering, but the management and sales and every other aspect that can affect safety). If software engineering requires licenses then open source cannot be used. Good luck starting from scratch and introducing other risks of proprietary solutions! An example: a Lambourghini tractor has a fault in the steering software that causes the tractor to overturn and kills a farmer in Nabraska. How do you expect software engineering licensing to prevent that?

jpc0 3y ago

> clean code, development cycles and and design patterns We can't even agree that these things are in fact good ideas. Singleton is a design pattern, generally considered a bad one but it has important uses when used correctly. Clean code is good but only when done the correct amount, when done in a zealous manner just slows down development and adds extra overhead which will again cause mistakes. If anything I feel design by contract will become more of a standard, look at the JPL recommendations, they don't explicitly call it design by contract but it's build into the spec. Not enough "software engineers" even know what invariants need to hold, what preconditions need to be true and what postconditions need to be in place. Don't believe me, look for the equivalent of: try { // some code } catch(...) { // Handle all these errors we didnt know about and handle explicitly } In almost any codebase and it will be there.