Defense
Hughes Budget Cutoff
08/23/2009 11:51 AM
This is one of the other stories that was alluded to in the previous entry (NASA Program Language Requirements). Unfortunately, it’s even more wasteful than the previous entry was in terms of time and money. Back in 1995, I was working for Hughes Aircraft Company, Santa Barbara Research Center (SBRC) on a project called Wedge Imaging Spectrometer (WIS). WIS was a hyper-spectral sensor capable of up to 722 bands of data from UV through Thermal IR, depending on the instruments used for each mission. Putting 722 bands of data in perspective to a typical computer display of 3 bands (red, green blue) is a little interesting. One way to think of it is that any pixel on a typical computer screen is generated from 24 bits of color, WIS generated over 8,000 bits of color per pixel.
While working on this project, we had budgets within Hughes for projects, hardware, software, etc., each budget essentially a different bucket that could not be mixed together. Early into the year, our software budget was cut just as we had a purchase requisition in the pipeline for Research Systems’ ENVI (now part of ITT). This is a high end image processing and remote sensing package that is aimed straight at the type of data WIS produced, so it was a natural match to help develop and analyze WIS products. The purchase requisition was for somewhere in the $8,000 range if I recall correctly, but we were unable to purchase it due to the budget cut. We still needed the functionality, of course, so that meant we had to build the functionality in house. I spent the better part of a year to rebuild a small percentage of the ENVI package for our needs. The following year, we put ENVI in as the first item to purchase for our project and received it immediately. The work I had been doing the previous year was migrated into ENVI in a few weeks’ time. Considering my salary, overhead costs, lost time to work on other tools, etc., Hughes un-saved about $90,000 by eliminating the $8,000 purchase order.
There is an additional bit of info in this story worth bringing up. During the year this budget issue took place, I switched from an employee to a consultant/contractor for Hughes and also began teaching IDL classes (ENVI is written in IDL) outside of Hughes for Research Systems. One of the items I negotiated with Research Systems as part of teaching the training classes was an ENVI license for my own use. The license I had was only for use on Mac systems, while Hughes was purchasing ENVI for Sun systems. By the time WIS was utilizing ENVI to a larger degree for processing and analysis, I was pretty much the only person familiar with the software on the team and I was working less on the project. About a year later, I left the SBRC division and started working completely on my own not too much longer after that.
I’ll cover starting up the consulting business in a future entry.
While working on this project, we had budgets within Hughes for projects, hardware, software, etc., each budget essentially a different bucket that could not be mixed together. Early into the year, our software budget was cut just as we had a purchase requisition in the pipeline for Research Systems’ ENVI (now part of ITT). This is a high end image processing and remote sensing package that is aimed straight at the type of data WIS produced, so it was a natural match to help develop and analyze WIS products. The purchase requisition was for somewhere in the $8,000 range if I recall correctly, but we were unable to purchase it due to the budget cut. We still needed the functionality, of course, so that meant we had to build the functionality in house. I spent the better part of a year to rebuild a small percentage of the ENVI package for our needs. The following year, we put ENVI in as the first item to purchase for our project and received it immediately. The work I had been doing the previous year was migrated into ENVI in a few weeks’ time. Considering my salary, overhead costs, lost time to work on other tools, etc., Hughes un-saved about $90,000 by eliminating the $8,000 purchase order.
There is an additional bit of info in this story worth bringing up. During the year this budget issue took place, I switched from an employee to a consultant/contractor for Hughes and also began teaching IDL classes (ENVI is written in IDL) outside of Hughes for Research Systems. One of the items I negotiated with Research Systems as part of teaching the training classes was an ENVI license for my own use. The license I had was only for use on Mac systems, while Hughes was purchasing ENVI for Sun systems. By the time WIS was utilizing ENVI to a larger degree for processing and analysis, I was pretty much the only person familiar with the software on the team and I was working less on the project. About a year later, I left the SBRC division and started working completely on my own not too much longer after that.
I’ll cover starting up the consulting business in a future entry.
NASA Program Language Requirements
07/11/2009 06:01 AM
I made a comment recently about arbitrary decisions and related expenses to a colleague that brought up a couple old stories. In 1996, while working for Hughes Aircraft in Santa Barbara, CA, I began work on a new satellite data project. The MODIS satellite sensor was being built by Hughes and I was tasked with building an algorithm test bed for it. The group I was part of had spent several years working with the IDL programming language and had sent me off to an IDL class at Research Systems’ (the IDL developers, now a division of ITT) offices in Colorado. I later went on to host and maintain the IDL FAQ, as well as teach IDL classes for Research Systems. Basically, I was a very experienced IDL developer at this point. Our group had also developed a substantial library of custom functions in IDL and used them regularly.
A week or two after beginning IDL development for MODIS, my boss dropped by and had a talk with me. As specified in the program specs, we had to deliver all new code in either C or PV-Wave, IDL would not be accepted. We pushed back for some clarification on that, and it was reiterated that IDL could not be used because PV-Wave was specified by NASA. This wasn’t a huge issue since PV-Wave was based on a copy of the IDL source code sold from Research Systems to Visual Numerics. This meant the core language and functions had a very large overlap and the companies were direct competitors in many of the same fields. In the years after the source code had been sold, both companies had developed it in parallel, but different ways. The main difference between the two were the GUI elements, which had diverged quite a bit from each other.
As it happens, a large portion of what I was working on required a GUI for the engineers to be able to quickly load, apply and view the results of varying algorithms, so this had a pretty big effect on me. Essentially, half of what I was very familiar with in IDL would have to be written differently in PV-Wave. Also, functions that had some options in IDL had different options in PV-Wave as both companies extended the language in different ways. So, development switched to PV-Wave, and eventually I got my footing in the PV-Wave manner of GUI design. I stopped grumbling about the differences and made several nice applications for the engineers to work with the MODIS data.
After about 3 months of development, we were demoing our applications for NASA on their systems when we hit a snag. After loading our code and data and bringing up the GUI to start processing some of the data, a dialog box came up indicating we were not licensed to load the data. After bringing in a couple of the technical staff, it was determined that the NASA team we were working with had not purchased PV-Wave for the project, they had just requested a demo license and had never run it beyond watching the demo screens. The demo had been enough to dictate that PV-Wave would be written into the contract and IDL would be excluded. While not exactly an arbitrary decision, it certainly wasn’t a decision based on a detailed analysis. It cost some additional time in development for me to come up to speed with the PV-Wave way of GUI design and the occasional issue of having to rewrite functions from our IDL library to work within the PV-Wave library.
The project continued on in PV-Wave of course, and was eventually completed, delivered and accepted along with all of the other software, hardware, manuals, etc. that you might imagine goes along with providing a sensor that will spend years operating in a satellite. Some time later, I also created the PV-Wave FAQ to go along with the IDL FAQ I was maintaining. As mentioned above, this took place in 1996 and MODIS is still operational at this time (July, 2009).
A week or two after beginning IDL development for MODIS, my boss dropped by and had a talk with me. As specified in the program specs, we had to deliver all new code in either C or PV-Wave, IDL would not be accepted. We pushed back for some clarification on that, and it was reiterated that IDL could not be used because PV-Wave was specified by NASA. This wasn’t a huge issue since PV-Wave was based on a copy of the IDL source code sold from Research Systems to Visual Numerics. This meant the core language and functions had a very large overlap and the companies were direct competitors in many of the same fields. In the years after the source code had been sold, both companies had developed it in parallel, but different ways. The main difference between the two were the GUI elements, which had diverged quite a bit from each other.
As it happens, a large portion of what I was working on required a GUI for the engineers to be able to quickly load, apply and view the results of varying algorithms, so this had a pretty big effect on me. Essentially, half of what I was very familiar with in IDL would have to be written differently in PV-Wave. Also, functions that had some options in IDL had different options in PV-Wave as both companies extended the language in different ways. So, development switched to PV-Wave, and eventually I got my footing in the PV-Wave manner of GUI design. I stopped grumbling about the differences and made several nice applications for the engineers to work with the MODIS data.
After about 3 months of development, we were demoing our applications for NASA on their systems when we hit a snag. After loading our code and data and bringing up the GUI to start processing some of the data, a dialog box came up indicating we were not licensed to load the data. After bringing in a couple of the technical staff, it was determined that the NASA team we were working with had not purchased PV-Wave for the project, they had just requested a demo license and had never run it beyond watching the demo screens. The demo had been enough to dictate that PV-Wave would be written into the contract and IDL would be excluded. While not exactly an arbitrary decision, it certainly wasn’t a decision based on a detailed analysis. It cost some additional time in development for me to come up to speed with the PV-Wave way of GUI design and the occasional issue of having to rewrite functions from our IDL library to work within the PV-Wave library.
The project continued on in PV-Wave of course, and was eventually completed, delivered and accepted along with all of the other software, hardware, manuals, etc. that you might imagine goes along with providing a sensor that will spend years operating in a satellite. Some time later, I also created the PV-Wave FAQ to go along with the IDL FAQ I was maintaining. As mentioned above, this took place in 1996 and MODIS is still operational at this time (July, 2009).