Thus the demand for the certification needs to come from the selfish needs of the certified profession.
First requirement is that there is an oversupply of qualified candidates. As the demands for software engineers shows no signs of abating I would claim attaining this first requirement would be quite hard. On the other hand, if supply of eligible candidates exceeded demand we would have a certification program done almost by itself - unless the big tech incumbents fought terribly against it, of course.
Is it? At one time, physicians, too, were not all that keen on the idea of licensing.
"David A. Johnson and Humayun J. Chaudhry's surprisingly engaging Medical Licensing and Discipline in America: A History of the Federation of State Medical Boards was published to commemorate the centennial celebration of the Federation of State Medical Boards (FSMB). It opens with the infamous John Brinkley, known for transplanting live goat testicles into men in order to 'cure' impotence, and segues neatly into demonstrating how vital licensure and discipline continue to be for the medical profession and the general public. The authors pepper the book with many other such examples, making the dry remote process of licensure absorbing and pertinent to the reader..."
Having seen (allegedly) senior software developers do architectural things equivalent to said ghastly transplant, I'm not so sure licensure for software engineers would be a bad thing anymore.
I'm not so sure medicine is the best example in managing a rational body work. It's still riddled with eminence rather than evidence based treatments. The disparity between the stuff that works - which is friggin amazing - and between what is at best invasive placebo is quite large.
But yeah, I agree, licensing if done properly can cut the tail of total nutjobs and incompetents. I'm not still sure if that can be the foremost motivator, though.
The problem is that although people moan about rubbishy software it very rarely physically hurts anybody and can be fixed in future releases. This means people are unwilling to pay the extra cost of software being more mature and 'engineered' on delivery. There's a lot of software that would be not be economically viable if it was to be held to a higher standard. If a bridge failing could be guaranteed not to hurt nobody and could be put right in a day or so but be like 1/10th of the cost structural engineers would be held to a lesser standard to.
That said, the financial cost of poor security that comes from a lower accepted quality may change what is acceptable over time for internet facing software. Even that is seemingly a long way off, look at the actual consequences for recent privacy and security breaches.
Sure, the initial impulse is cheaper if you hire all greenhorns but after a year? after five years? When the business decides that they want to move from AWS to Azure for X immutable reason?
1- Let private and public schools be. They can issue their engineering diploma as they like (to a certain extent).
2- Have a national committee that evaluates graduates and gives "national diploma of engineering" based on a number of criteria.
3- Watch the committee slowly become irrelevant as the private sector companies don't care about the national diploma and just wants qualified people.
But the state can't afford to piss-off the private sector, otherwise unemployment rates will go through the roof.
Private sector companies do care about the actual Engineering degree so people who graduate from non-certified schools tend to have a lower starting salary.
I graduated from a non-certified school and my starting salary was higher than friends from a certified school, for an identical software engineering position.
There is another organism that does the "equivalence" of diploma called "ordre des ingénieurs", I never bothered to do it.
Edit: I would be curious to see, if more people are willing to indicate their years of field experience in this particular thread. I'm crowding 23.
For the record, I am completely against any kind of certification in this field... which is actually already a dozen different fields, at the least. (I have no experience in Machine Learning or Wordpress plugins, both of which are actual jobs you can make money with.)
The quality of software for lolzcat apps could remain shitty, but the quality of firmware for FCC approval would go way up.
In order for quality to increase for infrastructure software, engineers need to risk going to prison. It worked for civil, chemical, mechanical, etc. engineers. A lot of people died on shitty bridges before they started locking shitty engineers up. Software engineering will be no different.
Do what they do for all other engineering fields: require a certified
engineer sign off on a product delivered to a regulated entity, and be able
to hold that engineer criminally liable if someone comes to harm from the
product they signed off on.
As to who would do this, there are organizations like the IEEE and the ACM that would be only to happy to help.
The question would indeed be one of bootstrapping: processes to convert on the job experience into more certifications and conversely to add appreciable demand for the certifications into the job market.
We do need software engineering. But we simply cannot treat it like every other discipline. We need better techniques, we need formal methods. We're still in the dark ages, and every other discipline has sacrificed many to get where they are. But we're simply not there yet, despite the fact that we've protected many already thanks to the likes of Parnas and Boehme etc.
I think the premise, "engineers need to risk going to prison." is facially ridiculous. I'm down with prosecuting actual fraud but you can't legislate quality. You can only protect diligence.
Dunno about the USA but the aerospace companies I've worked for in Europe already require multiple sign-off from engineers.
"Engineers" meaning people who got an engineering degree (typically 5-6 years for a master) from an accredited university.
https://m.ieee.org/education_careers/careers/certified_softw...
No one bothers or cares much. Just call yourself an "engineer" if you want to.
https://www.theatlantic.com/technology/archive/2015/11/progr...
As others have said, there are already engineering societies and you can become a professional/certified engineer but there is not really much demand at the moment. I'd really prefer trying to set up a parallel system that achieves other goals (improving the overall ability of programmers).
What use is it to be able to create an independent project when 100 per cent of your work consists of delivering implementations according to specifications created by other people, using interfaces created by other people?
Being able to create a single-developer green field project takes you about one fifth the way to being able to survive in large projects (where "large" may also mean a very simple project embedded in layers over layers of process, politics and regulations).
Yes, the real question is more one of bootstrapping demand than finding associations to provide credentials. I considered trying for a Software PE because my current job (which is an environmental engineering firm where PEs in civil/environmental/electrical/et al are required/needed/present) would give me a small salary bonus for a PE title (and job title distinction that matters to my ego), but the effort involved doesn't seem worth it if the distinction is largely ignored by the software industry itself.
1. what makes a certified software engineer? - eg. will embedded, back-end guys, front-end guys, SREs, have similar certification processes, or will they differ, and if they differ, what happens when someone, wants to move?
2. who does the certification, the community or some bureaucratic board?
3. what guarantees that the certification process keeps pace with the ever changing landscape?
4. what guarantees that those with the authority to certify don't use it selfishly?
https://mises.org/system/tdf/Liberalism%20In%20the%20Classic...
... for an explanation of why.
In many ways the "certification" for software engineers is a misnomer. For me, github is a certification of sorts - a (biased) view: good engineers code for passion not money. I'm sure there's lots of good engineers that don't have a github, but I prefer those that do.
They somehow decided that they needed to set insanely hard exams, so that 97% of the students fail (not an exaggeration). So they had a nice monopoly and could command huge salaries.
Most of those students that fail now transfer to private universities and end up being perfectly acceptable engineers, programmers, etc.
But the very few that end up graduating (about 1 in a 1000) are really very good at problem solving and I doubt that any one of them that chooses CS would fail fizz buzz. They're required to write their own compilers, write a hardware driver, and other stuff, up to what would be postgraduate level in the U.S.
The market doesn't really recognize the insane stuff they had to go through and often pays them the same as a graduate from a private university (which is "easier" by virtue of being sane, I'd say most are perfectly acceptable in the exigence level)
http://www.elpais.com.uy/informacion/ingenieria-solo-3-6-de-...
http://noticias.universia.edu.uy/en-portada/noticia/2013/05/...
2) I'd propose a tiered system of software development licenses, involving passing tests such as "sort this linked list". Preferably do them on a whiteboard, just like in the real world.
3) I'd forbid access to a compiler to anyone without their software development licenses.
Or maybe I'd just go with an amorphous mess of university degrees, short courses and on-the-job experience.
Frankly only a guild cares whether you're a master craftsman. I see greater value to customers in the latter two, especially if S/W products were held to a standard of 'quality', esp efficacy and reliability. Then the S/W dev process could adopt a quality assurance process like that of housing construction, in which a building code exists and defines metrics of product performance that must be met by the builder through iterative inspections and a formal compliance process.
Should such a process exist for all software? No. But I believe it should for some software products, like those in automobiles, medical devices, and essential infrastructure, etc. Do such formal dev processes benefit from their practitioners having some sort of formal certification themselves? Probably not. It's the process and product that's needs certification, not the craftsman.
But on the other topic. The PE, which is the engineering certification in the US has a software specialization already. And I don't plan to get it. Even though I meet one of the most difficult qualifications which is having a degree from a school where Computer Science is accredited as an engineering program. Same reason my wife who is a Process Engineer (an electrical and/or mechanical engineer that engineers processes and machines for mass production) doesn't plan on getting her's despite having a Master's degree in biomedical engineering. No employer is looking for it and it is absurdly expensive in both time and money.
I think this XKCD applies: https://imgs.xkcd.com/comics/standards.png
In software development, these and other benefits are not as critical or very hard to achieve even with strong enforcement.
It was a fairly controversial appointment.
I'm not entirely sure what specifically the poster thought he should have been disbarred for, but a number of his views have made it easy to argue about the quality of service he has given.
Unbounded complexity is a distinct trait of software. The most important, most regulated and most prestigious software engineering tasks are hands down mostly about doing relatively simple things but controlling complexity. To a lesser degree, when writing code every programmer is actually working to control complexity.
Once things get complex then nobody, not even the brightest brain, can get anything done anymore. So the first priority is to actually avoid too much complexity and to reduce it further will cost time and money.
This means we can do simple things well if we want to. We do this for narrowly scoped projects such as aviation-grade software, rocketry and medical software et cetera. It costs, and we can do it, but that's only because we already slashed out most complexity out of the window before we even started. Instead of general-purpose software we're writing very specific-purpose software.
Using the same principle but working on top of abstractions we can do complex things well in software, too. But those always come with a caveat about when and where the abstraction might fail. Most software is like this but that is also the sort of software which is no longer bridge-building grade. We don't build bridges whose design is theoretically sound given a few hasty assumptions, but with the possibility that when those assumptions might fail the bridge would come down. Certified software engineering can't fix that because they would have to start from the ground up to cover all their bases and then they couldn't get very high from there.
Certification is no silver bullet. Complexity is already managed where absolutely necessary and where there is the money to back it up. Requiring a certified engineer with legal responsibility in the general case would just make most software development stop entirely because anyone with the slightest understanding of programming would never sign off the software we currently want to run, and writing properly engineered software to handle what we currently want to run would be just prohibitively expensive.
I understand why those are not enough, but it would be nice not to have to prove you are competent from ground up every time you want to change a job. Hence, certification, etc. But I have no idea how to do it well, though I do hope someone else spends couple of years figuring it out :)
A lot of people currently in the industry wouldn't qualify if Professional Engineer-style certification were instituted and even those that do would be held to a lot higher standard than they are now.