[duped]

> As a result of how young the profession is, there are few universally accepted practices and standards.

I wish the meme of "software engineering is young" would die. This profession is not younger than any other technical profession, in the modern sense. It was born out of prior practice and is still taught using the same techniques and philosophy. We are not special.

Furthermore, modern engineering is a mid to late 20th century practice - across all domains - not just ECE. We inherited some practices of the first industrial revolution, but by and large the techniques and tradition of education of engineers is consistent across the disciplines and evolved out of the post-WW2 marketplace for new technical products.

It would serve the author to remember this well coupled with the following :

Engineering is the discipline of systematic problem solving. Computer science is the mathematical study of abstraction. Software development is the practice of applying computer science to the domain of engineering.

This results in a force amplifier - much like a lever - but rather than creating torque what we're doing is amplifying the ability of creative problem solving to be applied and re-applied without re-engineering complexity. That abstraction and reuse propagates throughout entire industries in ways that are now invisible because they have become ubiquitous.

"Does the software industry learn?"

Well of course it does. We encode our learning of the problems we face everyday. The chips powering the computer I'm typing this on was designed with software that prototyped and ultimately yielded their design; packaged on circuit boards designed with software that automated hardware engineering checks to validate the design; encased in an enclosure designed with software that encompasses decades of 3D design and visualization technology; all fabricated using hardware and software tools with ambiguity resolved through digital communications that can be seen as a recursion of this paragraph.

It's turtles all the way down.

If you think we aren't learning everyday, propagating that learning, and preserving it for generations to come you do not understand the practices we undertake everyday. There is so much learned technique, practice, and theory encoded into the basis of our everyday lives it now seems so invisible you can blog about it.

[T-zex]

Good point that software "industry" is not new, but I would argue that it is not an industry in a literal sense or at least it is a special industry. The special thing about software is that it is governed by the social aspects a lot.

And because of this, software has poor standardization practices.

Engineers in other sectors could prove their qualifications by showing certification diplomas, even education and years of experience would count. In software your qualification would be determined by some random dude and how well you fit his CS fetish of the month and that is it. Experience and education is only important while filtering CVs. If you designed a chip, an aircraft or skyscraper it is immediately impressive. If you built an FX trading platform it means almost nothing if you are a bit skeptical about pair programming.

It also applies the other way round. If project uses microservice architecture, what exactly does that mean? The result would be a wildly different if you compare such projects at FANG and some investment bank. How software is tested and released will be different in any team. And how that affects the poor developer will vary too. What is a good software? We can have an opinion, but there is no formal definition.

And because of this fragmentation and fluidity software as and industry is doing very different things. It will learn in some cases in others it will be incredibly ignorant.

[austincheney]

The software industry is young, if not in a literal sense then certainly in a figurative sense.

Other crafts define their professionalism according to a standard baseline defined by governance and credentials. Examples of credentials are licenses and certifications. Examples of other crafts that require credentials: medicine, law, engineering, flying, driving, real estate, information security, networking, food preparation, education, public securities, and many more. When this is brought up in software the result is excuses and whining, hardly an indication of maturity.

The problems with the industries exaggerated immaturity result in profuse subjectivity. There is always a perception, at hiring, that software developers are rare. Perhaps poorly trained or developed less than desired expectations but software developers are not rare. Nonetheless the problem is exaggerated in a cycle of attempts to increase availability among an undesirable candidate pool by abstracting away many challenges inherent to the practice. This is cyclical because instead of bridging a training or development gap it instead breeds entitlement and insecurity that is paid forward. Since there are no industry standards of acceptable practice this cycle becomes a race to the bottom.

This is the very essence of young.

[dogleash]

What exactly do you think licensing would provide that a formal quality system couldn't?

Software has a deliverable that can be tested prior to delivery. And there are domains where software has to be developed within a QMS, those domains have quietly built elaborate process and systems dedicated to quality of their software.

Using licensing to ensure quality results is an easier sell in scenarios where such a system can't exist, like when the practitioner doesn't get (m)any retries.

Are we worried something is falling through the cracks of the quality system approach? Are there properties of a deliverable that those systems can't ensure?

Some product domains are so inconsequential to life that it would be a laughable non-starter to write bars for their quality into law. Is a blanket licensing requirement a way to get at practitioners operating in those fields anyway? Because the individuals will be more of a pushover and easier to wage a public campaign against than the company they hypothetically work for?

[austincheney]

> What exactly do you think licensing would provide that a formal quality system couldn't?

A uniform minimal accepted standard and ethics. Excuses against licensing generally arise from people who don’t understand it from a lack of experience, an argument from ignorance.

https://www.logicallyfallacious.com/cgi-bin/uy/webpages.cgi?...