3 ms·

Well that's a start. They don't offer one in my state/country yet but I'll definitely take it when they do. I think it's a necessary move. Liability should def

Well that's a start. They don't offer one in my state/country yet but I'll definitely take it when they do. I think it's a necessary move. Liability should definitely be on the table as well at some point. The undertones at Blackhat and Defcon seemed to suggest some people think it's inevitable. There's nothing to be lost by adopting a more rigorous process and only much to gain. Especially with the advances in tooling we have available: TLA+, Unit-B, Agda, Ada... etc. I have a feeling Sussman may be right when it comes to lawyers and software -- the safest thing to do for a system where liability is a concern is probably to shut off in the face of a sub-system failure... which is probably less than ideal. However I'm confident there could be ways to specify a system that can do "reasonable" things in the face of non-terminal situations (ie: if I lose my writing arm I still have another one that's capable of doing a reasonable job to carry out the task).

tclmeelmo 11y ago
> Well that's a start. They don't offer one in my state/country yet but I'll definitely take it when they do. It's not that simple. The quickest path to licensure is to graduate from an ABET-accredited engineering program (4 years), pass the fundamentals of engineering exam (which, likely being the "other disciplines" exam, requires general knowledge of engineering and science), perform engineering work supervised by a licensed engineer (I think you typically need 3 references), document your engineering work time (4 years are needed with a BS), and then pass the principles and practice in engineering exam. There are alternative paths that differ on the state level, but they take years longer, e.g., lacking the accredited BS would require something like 8 years of experience before one could sit for the FE exam. I think there's also a plan to require an MS at minimum to sit for the PE exam. Point being, licensure is far more involved than passing one exam.
- deleted 11y ago
  [deleted]
- agentultra 11y ago
  I've been shipping software for almost 14 years. I've been picking up formal specifications, predicate calculus, etc rather well I think. I'm not afraid of doing the work: it's important! And besides, the maths are beautiful.
  - tclmeelmo 11y ago
    Unless those 14 years were under the supervision of a PE who was stamping your work, your work experience isn't meaningful for the purposes of licensure. Why would it be? I view the PE in software as being for managers on software-intensive engineering projects, say for example, plant controls or electronic medical devices. If you look at the current licensing path, you'll see that it requires deep domain-specific engineering knowledge (e.g., mechanical engineering) or broad engineering knowledge (e.g., statics and dynamics + fluid dynamics + materials science + ...), neither of which are common among self-labeled software engineers: this is why I view a PE in software as being intended for a controls engineer who does a lot of software projects (as one example). It's not really relevant for most software domains, nor is it intended to be.
    - agentultra 11y ago
      I see. I'm still enthused about introducing more formal methods and "engineering" practices into software development. I think it is very useful and indeed as the world becomes more reliant on open-source software... there needs to be some sort of protection of the public good, no? Thanks for taking to time to respond to my, sometimes naïve, comments.

tclmeelmo 11y ago

> Well that's a start. They don't offer one in my state/country yet but I'll definitely take it when they do. It's not that simple. The quickest path to licensure is to graduate from an ABET-accredited engineering program (4 years), pass the fundamentals of engineering exam (which, likely being the "other disciplines" exam, requires general knowledge of engineering and science), perform engineering work supervised by a licensed engineer (I think you typically need 3 references), document your engineering work time (4 years are needed with a BS), and then pass the principles and practice in engineering exam. There are alternative paths that differ on the state level, but they take years longer, e.g., lacking the accredited BS would require something like 8 years of experience before one could sit for the FE exam. I think there's also a plan to require an MS at minimum to sit for the PE exam. Point being, licensure is far more involved than passing one exam.

deleted 11y ago
[deleted]
agentultra 11y ago
I've been shipping software for almost 14 years. I've been picking up formal specifications, predicate calculus, etc rather well I think. I'm not afraid of doing the work: it's important! And besides, the maths are beautiful.
- tclmeelmo 11y ago
  Unless those 14 years were under the supervision of a PE who was stamping your work, your work experience isn't meaningful for the purposes of licensure. Why would it be? I view the PE in software as being for managers on software-intensive engineering projects, say for example, plant controls or electronic medical devices. If you look at the current licensing path, you'll see that it requires deep domain-specific engineering knowledge (e.g., mechanical engineering) or broad engineering knowledge (e.g., statics and dynamics + fluid dynamics + materials science + ...), neither of which are common among self-labeled software engineers: this is why I view a PE in software as being intended for a controls engineer who does a lot of software projects (as one example). It's not really relevant for most software domains, nor is it intended to be.
  - agentultra 11y ago
    I see. I'm still enthused about introducing more formal methods and "engineering" practices into software development. I think it is very useful and indeed as the world becomes more reliant on open-source software... there needs to be some sort of protection of the public good, no? Thanks for taking to time to respond to my, sometimes naïve, comments.