I have an idea that the "software engineering" industry is currently, in terms of maturity, where electrical engineering was in the early 1900s. Software is now a core part of the infrastructure of developed nations, but development is still very haphazard. Electrical engineering benefited from the implementation of standards and quality assurance that come with codes and professional licensing. Software engineering, *at least in certain critical applications*, would benefit from the same level and kinds of oversight. ---- **Background:** As far as I can tell, this idea [first occurred to me](https://twitter.com/joeld/statuses/844168364) in a discussion in June of 2008. I later wrote up a [draft](http://t.co/v6TlLb8n) of my thoughts in this area which I [made public](https://twitter.com/joeld/statuses/208309131566780416) in May 2012. ---- The issue kind of came to the forefront again with the `healthcare.gov` rollout and ensuing trainwreck. The inimitable Paul Ford took the opportunity to argue that this is a perfect example of [why government software should follow open-source development principles](http://www.businessweek.com/articles/2013-10-16/open-source-everything-the-moral-of-the-healthcare-dot-gov-debacle) practiced in much of the private software industry. I agree that publicly-owned and managed software is not only *a* candidate for the application of open-source principles but perhaps *the ultimate* candidate. However, I don't think open-sourcing government IT is going to be the whole solution, nor is the solution "a more agile process" [as some think it would be](http://readwrite.com/2013/11/04/sorry-open-source-isnt-the-panacea-for-healthcaregov). ---- Software engineering as a profession currently suffers from a basic level of immaturity. ---- Tom Limoncelli: > You might be saying to yourself, "But Tom! I can't predict every precursor to an outage!" No, you can't, and that's a bug. **That is a bug with the entire freakin' multi-billion dollar software industry.** Any time you have a user-visible outage and you can't think of a way to detect it ahead of time: file a bug. (from [*Stop monitoring whether or not your service is up!*](http://everythingsysadmin.com/2013/11/stop-monitoring-if-service-is-up.html), emphasis added) ---- > Sure enough, this week investigators are focusing in on electronics as a potential culprit behind Toyota's woes. Meanwhile, the auto maker has admitted that it has experienced problems with braking control software used in its Prius line and has since updated the software to correct the problem. So far, the model is only being recalled in Japan. > > Many drivers would be shocked to know that, when it comes to automotive controls, drivers increasingly fly by wire. A few years ago it was Airbus that ushered in an era in which electronics replaced direct hydraulic controls in airplanes. Automobiles have since followed. Gone are the days when the accelerator or brake pedal were directly connected to the throttle by a physical connector, such as a cable. Today for many makes - not just Toyota - electronics [specifically, software] act as the intermediary. -- [*Toyota's Lesson: Software Can Be Unsafe At Any Speed*](http://blogs.computerworld.com/print/15547) ---- Another argument for software licensure and code/firmware inspections: the dark side of the so-called Internet of Things: > Reports coming out of Russia suggest that some Chinese domestic appliances, notably [kettles, come kitted out with malware](http://www.theregister.co.uk/2013/10/29/dont_brew_that_cuppa_your_kettle_could_be_a_spambot/) — in the shape of small embedded computers that leech off the mains power to the device. The covert computational passenger hunts for unsecured wifi networks, connects to them, and joins a spam and malware pushing botnet. The theory is that a home computer user might eventually twig if their PC is a zombie, but who looks inside the base of their electric kettle, or the casing of their toaster? — [*Trust Me (I'm a Kettle)*](http://www.antipope.org/charlie/blog-static/2013/12/trust-me.html) ---- > Today at the Chaos Computer Congress (30C3), xobs and I disclosed a finding that some SD cards contain vulnerabilities that allow arbitrary code execution — on the memory card itself. On the dark side, code execution on the memory card enables a class of MITM (man-in-the-middle) attacks, where the card seems to be behaving one way, but in fact it does something else. On the light side, it also enables the possibility for hardware enthusiasts to gain access to a very cheap and ubiquitous source of microcontrollers. -- [On Hacking MicroSD Cards](http://www.bunniestudios.com/blog/?p=3554)