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.<p>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.<p>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.
I think its difficult to find this kind of regulation for SE partially because its so new and not well understood compared to other engineering professions. What is software engineering? The kinds of things that would regulate, say, programming an operating system kernel is not the same thing as someone who makes wordpress templates. Yet both would describe themselves broadly as Software Engineers. What is the difference between the aforementioned wordpress-template-maker and someone building a full web application in React? Where is the line that divides "Engineering" begin and end?<p>I can see a regulatory body develop certifications around software engineers that develop critical infrastructure or spacecraft, where a single failure is catastrophic, but that expertise might not apply for the person making the interface app for the same piece of software (or working in some other layer of the stack that is not so stringent). Is that person "less" of an engineer? It opens the door to institutional bias towards what is considered "proper" engineering, and much like relying on formal education for hiring, provide a poor heuristic in hiring practices.<p>However I think that we will eventually get there once we figure out collectively what "place" software has in society, once these divisions settle down and become better understood, then we can figure out how to regulate each properly. I think this could be 50-100 years from now.
How would we regulate software engineers? Badly.<p>We don't yet know how to reliably balance desirable goals in software development, such as delivering a certain level of quality and reliability, or delivering on time and on budget. That immediately undermines aspects such as proof of competence or ongoing training that are usually associated with regulated professions.<p>Moreover, I imagine the people in the industry who would be closest to getting these things right are probably too busy working on building real systems to spend much time teaching or assessing. If government officials started trying to set up a professional accreditation scheme for software developers with real legal weight, how many people here seriously believe the result would <i>not</i> be exams in Agile Software Craftsmanship Manifesto Driven Development, written and assessed by high profile and no doubt highly paid consultants whose total contribution to actual working code in high reliability or otherwise important systems is less than the contributions of at least half the people reading this comment?<p>We're not ready yet. With luck, we might be within at least some of our lifetimes, but I wouldn't bet much money on it. And in the meantime, any attempt to set this up would surely be subject to instant regulatory capture by exactly the kind of vultures our industry needs to move away from if standards are going to improve.
The first thing needs to be a culture change: "move fast and break things" is not an acceptable philosophy when you're dealing with millions of people's private conversations.
Probably similar to how other professions are regulated. Educational requirements, internship requirements, licensing, yearly continuing education, etc.
Software engineers are not professionals like doctors, lawyers, or chartered accountants. Real professionals have a degree of autonomy and their primary obligation is to the ethical standards of their profession, not to their employers.
As to the discriminatory and societal problems you write about, I don't know.<p>But there are certainly standards for particular fields of applications, like medical IT, enforced through stricter liability laws in that field.<p>In the 1990's and 2000's there was also a very long push for standardization (POSIX/SUSV, programming languages, SQL, SGML/XML, IP protocols, etc.). These efforts (and the success of Java) was also seen as a measure against Microsoft becoming predominant in the 1990's by many developers.<p>But in this decade, it seems like this isn't anymore a priority. A guy here on HN recently wrote that he'd never consider a language environment lacking a "canonical" or solitary implementation (like, say Ruby, Python, PHP, Perl, or other languages tied to their runtimes have). I found this very interesting, as it's the opposite of what I'm doing (I use only use languages having a language spec and multiple implementations).<p>I also see it as a generational phenomenon. Look at node.js today. Back in 2011 or so it started as a really practical asynchronous server-side JavaScript runtime based roughly on CommonJS platform specs also implemented by other JS runtimes. Nowadays, the entire reason to use JS in the first place, its ubiquity/portability, is completely lost, and node.js build setups are approaching or even surpassing J2EE-ish levels of complexity/absurdity (webpack, babel, angularjs, etc.).
I think there are a few really big problems. First is that nobody really knows how to build reliable software. Well, maybe somebody somewhere does, but there is no standard established method that can be studied and is known to work. Second, software is a set of instructions to accomplish something. There really is no method to design for a set of unknown instructions. Third, this leads to massive confusion over what design even means with respect to software. Ask 100 software developers what they think design means, and you will get 100 different answers. Fourth, many software projects are reliant on a massive stack of APIs to accomplish anything. It is often not known if these APIs are bug free, or exactly how they are supposed to be used. There are frequently unexpected complications using APIs. Sometimes just using third party APIs becomes a research and development effort. How we build anything is rapidly changing, because the community is still trying to figure out how to do it better. User Interfaces on the web is the most glaringly example. Nothing seems to survive for more than a year or two in this space. Many in the community worked extremely hard to get degrees in Computer Science or something similar and it is not enough. If there was knowledge that worked, wouldn't it be imparted through a college curriculum? In my experience, the upper level managers know nothing about software development and create deadlines that are impossible to meet. Software is something not amenable to being rushed. Code of any quality takes a lot of thought, time, consideration, care, analysis, testing, documenting. It all goes out the window when management starts dictating that the code must ship.
This question comes up once in a while. One solution to the complete lack of regulation would be to have something like a bar association similar to how lawyers regulate their profession. It wouldn't have to be a legal requirement, but it would at least set a standard for membership.
Free speech. First Amendment covers source code and similar expressions. Regulating free speech is virtually impossible. That is where the whole project stops.
Regulation is a wrong word. Regulation is something pushed to you from above, something that you did not ask for and that you'll try to evade using that programmer-brain of you.<p>What we need is something that clearly comes from fellow developers.
Regulation would have to start with simple coding standards. Updated yearly. Much like building codes. A project could pick what standards they wanted to adhere to, and then everyone on the project would have to adhere to those standards -- the whole project would be audited by a third-party after the fact for compliance.<p>There are plenty of good, short, concise coding standards to draw from. Especially useful in giving non-technical people the confidence that things were built consistently... if not correctly even. This is about as simple as it gets:<p>* WordPress Coding Standards – Make WordPress Core || <a href="https://make.wordpress.org/core/handbook/best-practices/coding-standards/" rel="nofollow">https://make.wordpress.org/core/handbook/best-practices/codi...</a><p>I'm sure there are others that aren't terrible.<p>I do think having more standards would help, standards defined by the devs on the project. If they get to choose their benchmark, then it's just about consistency of approach. Not a bad thing, right? Currently it's the wild west, and the only thing a dev can do is say, "It's my word against theirs, their code is bad."