There were enough usability problems with them

Agreed, but you're going to have usability problems when the use of a poor UI continues to be dictated from above despite the opinions of the people that actually have to use it.

GUIs are suppose to be less work, not more - typing is more work (as the AC pointed out)

They're better for some things, not as good for others. I can pop up a command prompt and type "copy *.txt \newdirectory" a lot faster than I can select the same files in the UI and drag them to another window. Conversely, if I want to copy everything in a particular folder between a range of dates, it's usually faster to use the UI.

If we were talking about metallurgists you'd have a point but most programmers I don't think size of local industry is their main obstacle to employment nor do I think the availability of workers is a driver for the size of the industry.

It isn't always, but depending on the kind of skills/work needed it can be. For instance, if you're primarily an embedded or industial automation developer, you're going to have an easier time finding work in an area that already does a lot of similar work, if for no other reason than there are non-trivial costs to running an embedded shop beyond just the software tools.

I can't speak for everyone, but I most certainly have turned down jobs when the salary wasn't adequate, and I know plenty of others than have as well.

Where I work now, we have two H-1Bs in our dev group of 12. Both are outstanding workers, and "legitimate" in that the company made a good-faith effort to fill the positions with Americans, but wasn't able to find people with the needed skills. Both are also paid at what I would consider to be an appropriate wage comparable to ours, and HR takes good care of them and makes a real effort to abide by both the letter and spirit of the law. This is how it's supposed to work.

Having said that, I've also worked at places that brought in H-1Bs in preference to American workers, even when the domestic workers were more qualified for the position. The reason? Money. At one place I worked (dev group of 14 with 4 domestic workers), the highest paid of that group was at about my experience and competence level, yet was paid less than 2/3 of my salary, and the company made it very clear to all of them that if they didn't toe the line, they were welcome to go right back to the five different nations they came from. Of course, personal experience doesn't mean it happens everywhere, but I've seen it enough to believe that there are a non-trivial number of employers that are in fact abusing the program.

The USA is unique in the resources it can devote, and therefore the scale at which it can operate. Which is to say, it is unique.

Okay, there's the misunderstanding - I hadn't understood you were talking about automated pre-checkin testing. I still am not seeing the need for "multiple compilers, multiple OSes, and multiple binary architectures" mentioned by the original poster for a product that is intended for a single platform. I frankly don't care whether my code builds and how it runs under Clang when we're a Visual Studio shop. Of course it's different for an open-source organization or a library vendor that needs to support multiple build/run environments, but those are rare exceptions. For most, we're talking about adding a lot of complexity, time, and maintenance costs to get a common code base for a number of different build environments that will never be used in production, particularly when there's a full-time QA department available.

And the benefit of this extra step is...?

On the flip side, we usually get bitched at if there are no unit tests for new code.

Developers may build with the IDE’s own compiler during development, but must ensure the code successfully builds with the centralized build system before committing.

Which is fine if you have the good fortune to have a mirror of the build system on your own machine, but in a lot of situations that isn't the case. Where I work we of course have the raw build scripts that we're expected to run locally before committing, but the CB system we use (Jenkins) occasionally just doesn't behave the same way because it has to do additional processing that we can't do locally, and sometimes will flag spurious errors that can only be fixed by clearing the workspace. Yay for incremental builds.

Multiple compilers, multiple OSes and multiple binary architectures should all be used and they should all be available to every developer on the network.

That's fine for something that's intended to run cross-platform, but not so much for something targeted to a specific operating system - code that's hooking Windows drivers isn't going to fare too well under Linux, for instance. As regards the unit tests, it's trivially easy to have code that runs fine in the unit tests but won't build for production because the test project contains the needed dependencies, but the coder forgot to put those dependencies into the production project. That's not an excuse for broken builds, but it does happen.

Your QA/Build process is seriously broken if you don't have one person or one team in charge of the build at all times.

We do have someone that owns the responsibility for the build system, but we also largely subscribe to the "you break it, you fix it" philosophy, and all of the devs have the tools to see when something breaks on the CB system right then and there. Social pressure among the devs ("Awesome job breaking the build, Bob. Did you even compile it before checking it in?") tends to help keep the builds clean, although there still are a couple of guys on the team that can be counted on to break the build a few times a week. 9 times out of 10 our busted builds are because someone didn't take the time to build all of the required configurations on their own machine before checking something in.

Rework the code so that it doesn't warn.

The problem is that sometimes that's not an option. For instance, a few weeks ago I was working with some code in VS 2010 that used named enums. Even though Intellisense was smart enough to recognize the enum without the explicit name ("enum" instead of "name::enum"), the compiler kept throwing "unknown symbol" errors if the enum was left as-is, and it would throw a warning indicating that the syntax given was only valid under C++11 if I explicitly scoped the enum, which failed the build because we compile with warnings equating to errors. Changing the enum itself to be enclosed in a class or at least a namespace probably was the right way to do it, but it would end up affecting a lot of other code, which in turn meant an extra regression pass for the QA guys. So, the only practical solution at the time was to disable the warning for that block of code, and re-enable it afterwards with a comment explaining the reason.

To carry a package, yes... allowing packages to be carried over cities at this point would be reckless IMHO.

But I was more disappointed by this example of what is not allowed: "Determining whether crops need to be watered that are grown as part of a commercial farming operation."

You don't need a big, heavy drone to take pictures, and there isn't much to crash into on farm land. (Granted, the max altitude must still be limited to prevent collisions with larger aircraft.)

Now, maybe satellite imagery is or will soon be the cheapest way to do this anyways, and maybe moisture imaging is best done in non-visible wavelengths that hobby drones don't have. But those are market concerns. I don't see much safety concern in buzzing around a farm.

So before continuing, your position is that the earth is warming, but is unavoidable, or will cost more to correct than to let happen, correct?