It's Time to License Software Engineering

They talk about dams and bridges being the birth of the engineering profession. Software though isn’t some newbuild home or bridge foundation or aircraft turbine blade, where I have to have faith in a system that stops crooks from selling me a house that will fall down, a bridge that will collapse, or a jet engine that explodes.

In fact, given the source code, build system, and some documentation, I — little old me! — can find bugs, fix them, and ship a working build. So can thousands of other fellow consumers.

I would rather advocate for statutory openness and freedom than trying to force quality control on what’s left of the closed, proprietary status quo. It would be a utopia indeed if we could get out of this rut where I (and my community of consumer tinkerers) are forbidden from unlocking our iPhones and Subarus and LGTVs to their full potential.

I call myself a Softwate Developer. I have an Engineering degree (Computer Engineering), but I don't wear a stripey hat, so I'm clearly not an engineer.

Employers are welcome to title me as they please, within the law. I enjoyed being titled as a Technical Yahoo, but only one company seemed to prefer that title.

https://www.vice.com/en/article/man-fined-for-engineering-wi...

When the world stops acting like this, I'll consider your proposal more earnestly. Until then, I'll dismiss your ideas with prejudice.

I have some open questions, though this is more implementation than concept - what categories of software would need what licensing? Is there a delineation for platforms with more or less effective sandboxing, e.g., mobile vs desktop platforms? Do we need licensing for non-mission-critical software like game development (not a trivial question given multiplayer transmits and parses data)? Memory-safe versus memory-unsafe languages?

Now, I can think of some good situations that should maybe require formal licensing, e.g., cryptography, though how to delineate that could be tricky. Certainly I would want someone building a cryptographic vault or library to have very good knowledge of cryptography - I am not sure this is needed if you are effectively dispatching to a known good library, but it is still possible to build highly insecure protocols on top of it. Wondering if I would want a single large license, or some kind of specialty licenses for such cases, though.

My biggest gripe though, is that I feel most of the problems of software come from companies behaving irresponsibly - collecting too much data, rushing features through, pushing top-down control and schedules making it difficult for engineers to push back for needs and to build systems effectively. A lot of corporations pretty much give marching orders to their engineers. Maybe if software engineers were licensed, and there was personal liability against one's license to disobey, it would create a strong incentive to not implement such systems. I have my doubts this would get implemented in the USA though, as we have already unfortunately mostly stood against regulations like the GDPR. Maybe the EU would do this - but I am not sure if it is a better strategy, if that is the intent, versus focusing the state on attacking companies with malicious intent and sending them directly out of business.

In engineering, if your assumptions are correct and you apply the formulas correctly, the bridge will not fall.

This is _not_ true of software, since it suffers from mathematical incompleteness. Computation is isomorphic to mathematics, and, just as there is no way to objectively estimate how long it will take to prove a theorem, there is no way _objectively_ estimate program properties, even simple things like "will this program ever print the string "xx". The proofs are variations of the Halting problem.

http://scribblethink.org/Work/Softestim/kcsest.pdf

Writing software is analogous to discovering the equations of physics of a bridge (physics/math) rather than applying them (engineering).

What I suggest considering instead of licensing is a voluntary GAP (good authorship practices) certification for a project, unique to each approved programming language, comparable to GMP (good manufacturing practices) in the pharmaceutical and food processing industries. Customers should then develop a culture of licensing commercial software only if it has this certification. As for who will certify, on what basis, at what cost, and how will it keep up with changes in the real world, all of these are good questions.

Software is mostly created by businesses. Business want to make money above all else. Creating software needs to take the absolute minimum amount of time and money and quality, both in code and the program functioning itself, is an afterthought.

Because software isn't a tangible product, like a car or a bridge or a building, there is a prejudice against having certification for the engineers. It's not "important" like tangible objects that easily (most of the time) have their flaws exposed. Less important means less emphasis on craft, and you shouldn't need a certificate to prove you can add code to a project.

This cat has been out of the bag for so long it's just preposterous to think it will change. The current model of, "just get anything that can move the project forward," be it offshore, AI, hordes, long hours, whatever, will always be the strategy.

If you want quality write it for yourself. Early on in my career I built a carefully curated set of moonlight clients that my employer(s) did not know about. Here I wrote high quality software on my own timelines, emphasizing quality over everything else, because I am a one man team and don't have time for support. Now those clients pay me more each month than my employer. Most months I just get a check in the mail and don't have to do anything. As one said, "It just keeps working and we even forget it's there." (most of the software is integration related).

So it can be done, you just have to have the priority be different than a business that is in it for the money alone.

(Please focus on his discussion of PE licensure, not on what developers should call themselves)

He says some software can be designed in our usual way: informal, fast, iterative, democratized, agile. But more and more software needs to be designed like a PE designing a public bridge: carefully, to stand strong for 100 years.

The social will for having real accountability and professional ethics just isn't there. If you license software, large companies will just outsource the stamps to small contractors who will legally assume responsibility while nothing else changes. All real accountability will be so sparse and random that all ethical complaints will be ignored. If this liability becomes large enough to effect anything, all tech companies will band together to bribe politicians to limit legal remedies in the laws themselves.

In the end, the only thing that will happen is that large companies will use these regulations to bludgeon smaller competition like they already do.