4. What does pay look like after bonding and licensing?
5. What do we do about H1Bs and foreign contractors?
6. How do you fight the, likely, trillions in capital that will be deployed from companies that contract engineers?
7. How do you fight the billions of dollars invested into agile project management?
8. What do we do with software written outside the country? Even if it's written by someone licensed in their country?
9. How long does adoption of new software take?
There have already been several failed attempts at licensing and achieving a PE status for software. It occasionally makes the news in IEEE. None of them have worked because none of them address these points. Worse, the ivory tower "we should seriously think about this" people address even fewer points than the organizations that failed. This battle has been fought and lost numerous times.
I think the pro-licensing crowd forgets that licensing implies there will be exactly one (maybe two) blessed languages. It may even mean one or two blessed editors, one blessed UML software, one blessed planning framework (waterfall), etc. The language will either be C++ or Java and that will be how we code for the duration of the licensing scheme. Don't believe it will be either C++ or Java? Well, simply ask what your government uses.
I'm not designing the whole licensure system in an HN post. If there was an actual, serious push for this, people would figure all those things out. I didn't realize there were already failed attempts--maybe the next try could learn from them. OP and I are fully aware this is a pipe dream, seeing how far along the "wild west" track we've gone.
I also don't believe licensing necessarily implies there will be one or two "blessed" languages or technologies. What might be hard is finding someone willing to sign off on 100,000 lines of unsafe C++ code vs. 5,000 lines of sandboxed Python.
I didn't intend for you to design the system but rather demonstrate every single hurdle it would have to overcome.
As for your hypothesis, I'd go the opposite. Dynamic typing would basically be untenable. I would NEVER sign off on anything hinting at dynamic code. I have had so much apparently well written, apparently well tested, dynamic Python code completely blow up in my face. That's why I suggest languages like C++ and Java. They have insane adoption levels and are where all the "probable PEs" probably work. While both are still weakly typed in a literal sense you can box the types in such a way the compiler, and therefore the engineer, can make promises. This is actually one of my main gripes of the industry in general. I am a Python developer. I predict Python will become the new Javascript. A language we should've, in hindsight, just let rot in the past. Just trying to standardized what safe concurrency and parallelism looks like in a post-licensing world gives me a headache.
It's actually a very good argument for the complete destruction of dynamic type systems in favor of a haskell-esque, rust-esque, ada-esque development methodology. I am not entire opposed to the idea though the cult of agile will beg to differ. The standard software engineers would have to rise to would necessitate a formal education and entire system we have would be upended. Everything outside of RTOS-level development is dynamic these days. It's weird knowing everything can blow up in your face and you'd never be able to predict why. Imagine a bridge builder saying we tested everything but there's still a 30% chance the bridge just implodes by itself.
I'm up for ravenscar profile Ada. I don't think 95% of the industry is on my side on that one though :).
I think you're misunderstanding how licensing works. It's very rarely the case that one technology is blessed and another is not. That may happen in cases like FIPS but for the majority of existing software regulation it's far more about threat modeling and showing that the threats are considered.
1. What language will be blessed?
2. What compiler will be blessed?
3. What does a PE look like?
4. What does pay look like after bonding and licensing?
5. What do we do about H1Bs and foreign contractors?
6. How do you fight the, likely, trillions in capital that will be deployed from companies that contract engineers?
7. How do you fight the billions of dollars invested into agile project management?
8. What do we do with software written outside the country? Even if it's written by someone licensed in their country?
9. How long does adoption of new software take?
There have already been several failed attempts at licensing and achieving a PE status for software. It occasionally makes the news in IEEE. None of them have worked because none of them address these points. Worse, the ivory tower "we should seriously think about this" people address even fewer points than the organizations that failed. This battle has been fought and lost numerous times.
I think the pro-licensing crowd forgets that licensing implies there will be exactly one (maybe two) blessed languages. It may even mean one or two blessed editors, one blessed UML software, one blessed planning framework (waterfall), etc. The language will either be C++ or Java and that will be how we code for the duration of the licensing scheme. Don't believe it will be either C++ or Java? Well, simply ask what your government uses.