A couple of key points: 1) Software development at NASA is unlike anything 99.999% of the tech heads here would recognize. The scrutiny and the level of detail and failover protection in their code is unbelievable. Lives are at stake with their code or at worst millions of dollars of hardware crash into the surface of Mars and an entire mission is ruined. For most of us, if we have a bug in our code we patch and life moves on. If NASA has a bug in their code someone may die. 2) I have a friend that works for NASA. After SpaceX's first successful launch I said to him "big deal, NASA gave them blueprints, designs so this wasn't much of an accomplishment". His reply was "no, NASA did go to SpaceX early on and offered assistance in design but SpaceX turned them away. SpaceX is in business to make money and they cannot carry the burden of triple and quadruple redundancies that NASA has in their spacecraft. NASA's designs are too expensive." So if SpaceX is using off the shelf software you should recognize that SpaceX is willing to accept defects in order to ensure their profitability. NASA's needs are fundamentally different; they are to protect life and missions. SpaceX will take risks that NASA will not(and BTW, go ahead and sign up for that ride on a SpaceX rocket knowing this). This is why I am sure NASA did not choose off the shelf software and decided to write it themselves. This post is way off the mark to call this just a pork play.

There are fundamental capabilities involved in developing appplications that involve the process of logic, scientific method that all come from a structured STEM education. Learning syntax and best practices for developers can only be useful when layered on top of a structured STEM education. Some of the capabilities that come out of that STEM education are the proper use of logic, scientific method and one of the most important items: knowing what you don't know. How many of us have worked with that self taught programmer running around acting like they are the be all end all when they don't know their head from a hole in the ground? When you work towards that degree in STEM you get a sense of humility from having to work so hard to get decent grades in those classes. Science, math and engineering is f'ing hard. You have an appreciation of the science, math and physics that go into developing something that the self taught programmer with the HS diploma simply doesn't have. Further, you can be d*mn sure that HS grad/self taught programmer wasn't taking AP calc and physics in HS otherwise they surely would have moved on to getting at least an undergrad degree in some STEM discipline. I did a lot of work with rules engine deployments in the late 90's/early 2000's with large financial organizations. The selling point of these rules engines was that you could take your business people and have them build the rules that were fed into the engines. It went poorly. The fundamental reason was the business people simply had no good base in logic to string together their rules so they actually worked. You end up with having a bunch of engineers having to support the business people because of all the logic errors/incompatibility of the rules built by the business people. And when the rules engine would choke on their rules the biz people had a difficult time figuring out the problem(s). These tools that are being created to allow anyone to create apps are certain to face the same fate as the rules engine. Fundamentally, an app needs logic, loops and blocks and that's where the breakdown will occur for the non-programmer building the app. You will always need the trained engineer for app development. All these tools can do is reduce the amount of grunt work necessary to build the apps. You will need fewer programmers to do app development and that's a win. And the developers that will be cut off the payroll because of these tools are those self taught ones that really don't know what they are doing anyway.

Certainly Amazon's domination of the E-Reader category has stifled innovation. But, in my opinion, the real root cause of the lack of E-Reader innovation isn't being highlighted: E-Ink. They've maintained a near complete monopoly on the electronic ink display market and have behaved accordingly. They have not produced any significant improvements in the technology in many years and, worse yet, have done nothing to bring down the prices of an E-Ink display. The recent Sony "electronic clipboard/notepad" introduction created buzz and excitement until users found out the price: north of $1k. Everything about the device is appealing except for the cost and it's a dealbreaker. The cost of that device is almost entirely driven by the cost of the E-Ink display. Until there is competition in the electronic ink display market the combo of E-Ink and Amazon will continue to choke off innovation. When we see a sub $100 BOM cost of an electronic ink display/A4+ size then you'll see innovation explode.

Yes, virtualization is great in the workplace for a couple of reasons, server virtualization as well as the ability to quickly and easily use OS images to test development. However, a huge potential consumer market is out there: a packaged virtualization technology for your mom and pop users, sandboxing their entire connection to the internet on the VM. We all know how your average user has their computer hosed six ways from sunday with viruses, malware, etc. What if we could put their browser/e-mail in a VM so that any viruses/malware/spyware can only hit the OS image? Then all we have to do is revert to the previous backup of the OS image and we're back in business? Sure, the virus kiddies will then try and exploit the VM but it sure seems like a better deal than having to wipe out you entire hard driver, re-install windows and all your applications in order to get back a clean OS.