4 ms·

> Engineering, as a discipline and as an activity, is multi-disciplinary. It’s just messy. I would qualify that and say "software engineering," as we understan

> Engineering, as a discipline and as an activity, is multi-disciplinary. It’s just messy. I would qualify that and say "software engineering," as we understand it today is messy. That's because it's not engineering as a recognized discipline (and seems to be the reason why we can get away with calling ourselves engineers and not be sued). If your process involves thinking immediately about how to write the solution in code you're doing a very sloppy form of engineering. If you're the kind to write notes down about your design and possibly share some kind of diagram/written specification... you're doing a very weak form of engineering. I don't think it would pass at Lockheed Martin or JPL. You need to be using formal methods and mathematically modelling, checking, and possibly even proving enabled actions on your state and the invariants you hope to maintain. You need to start thinking at a higher level and have liability and all of those other things that drive you to get more guarantees and rigor out of your process. My theory is that "formal methods" are not out of the reach of hackers, developers, and the wider industry. With a smattering of complicated-sounding things like predicate calculus and temporal logic you can get a psuedo-language for exhaustively checking your designs before you write the code to make sure you haven't forgotten important things like building the right solution. It's really cool stuff... I'm learning TLA+ right now and loving it. I hope more people will find it as useful as I do.

jnbiche 11y ago
> That's because it's not engineering as a recognized discipline (and seems to be the reason why we can get away with calling ourselves engineers and not be sued). I'm consistently surprised at how little programmers/developers and software engineers are aware of the progress made here over the past 5 years. Software engineering most definitely is a recognized engineering discipline nationally and in most states: http://ncees.org/about-ncees/news/ncees-introduces-pe-exam-for-software-engineering/ http://ncees.org/about-ncees/news/ncees-introduces-pe-exam-f... http://insight.ieeeusa.org/insight/content/careers/97473 http://insight.ieeeusa.org/insight/content/careers/97473 We can debate whether or not these developments are good for our profession (good, in my view). However, it's no longer disputable, at least in the US, that software engineering is a recognized engineering discipline. At least unless you don't recognize the authority of the IEEE/NCEES in this matter (in which case you don't recognize the credentials of most US engineers from any engineering discipline). That said, I strongly agree with your emphasis on formal methods. I'm disappointed that software developers/engineers don't put more emphasis on these tools, even if they fail to convince their managers to actually use them. Yes, we don't need to use formal methods for a few jQuery scripts on a web page, but there are lots of places where they could find good use. As one example, for general application development, Ada/Spark is an excellent example of an engineering-focused language and environment, and I wish other languages took this approach. For embedded designs, solutions like Ivory (and Ada, too) provide a fairly rigorous approach to software development. TLA+ is another interesting tool (that I know relatively little about). These are the sorts of tools we need to emphasis. Unfortunately, most clients/companies aren't really interested in these methods, even when they're building applications where security matters. There are obvious exceptions, like some medical and avionics software, but even the automotive software I've looked into seems to have been developed in a sloppy, ad-hoc manner (and surprisingly, often by people trained as traditional engineers).
- agentultra 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. 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.

jnbiche 11y ago

> That's because it's not engineering as a recognized discipline (and seems to be the reason why we can get away with calling ourselves engineers and not be sued). I'm consistently surprised at how little programmers/developers and software engineers are aware of the progress made here over the past 5 years. Software engineering most definitely is a recognized engineering discipline nationally and in most states: http://ncees.org/about-ncees/news/ncees-introduces-pe-exam-for-software-engineering/ http://ncees.org/about-ncees/news/ncees-introduces-pe-exam-f... http://insight.ieeeusa.org/insight/content/careers/97473 http://insight.ieeeusa.org/insight/content/careers/97473 We can debate whether or not these developments are good for our profession (good, in my view). However, it's no longer disputable, at least in the US, that software engineering is a recognized engineering discipline. At least unless you don't recognize the authority of the IEEE/NCEES in this matter (in which case you don't recognize the credentials of most US engineers from any engineering discipline). That said, I strongly agree with your emphasis on formal methods. I'm disappointed that software developers/engineers don't put more emphasis on these tools, even if they fail to convince their managers to actually use them. Yes, we don't need to use formal methods for a few jQuery scripts on a web page, but there are lots of places where they could find good use. As one example, for general application development, Ada/Spark is an excellent example of an engineering-focused language and environment, and I wish other languages took this approach. For embedded designs, solutions like Ivory (and Ada, too) provide a fairly rigorous approach to software development. TLA+ is another interesting tool (that I know relatively little about). These are the sorts of tools we need to emphasis. Unfortunately, most clients/companies aren't really interested in these methods, even when they're building applications where security matters. There are obvious exceptions, like some medical and avionics software, but even the automotive software I've looked into seems to have been developed in a sloppy, ad-hoc manner (and surprisingly, often by people trained as traditional engineers).

agentultra 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. 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.