|
There's three projects I've worked on that I've been particularly proud of. First was the Airfields Database. The year was 1989. I was just hired with a fresh BSCS degree, and working at what was then the Defense Communications Agency, in the basement of the Pentagon. My full TS/SCI clearance investigation was still ongoing, so I couldn't do any of that work. I only had an interim TS clearance. So that meant they had to find work for me to do in the several months I still had to wait for the clearance investigation to be finished. They decided that the Airfields Database was in the most need of help, and so that's where I went. The Airfields database, I was told, had a record of every single air base, air port, air field, road, or strip of grass where an aircraft had been known to take off or land there, even if it was just for an emergency. It had location information, runway length, runway direction, runway width, weight limitations, apron parking space, and almost a hundred other data elements that it tracked for each location. The software ran on the classified WWMCCS military mainframe systems, and was written in COBOL 66. It was our job to bring it "up to date" with COBOL 77. There were two main code paths through the system. One where the operator selected the different fields that were relevant and what the constraints were, and one where all fields were considered relevant and you had to provide the constraints. I had the bright idea that we should eliminate the longer code path and only have one set of routines we had to modify, as we could simulate that longer path by pretending that the user had selected all fields in the other code path. Well, it worked. We chopped out about 40% of the code from the system. During the process, I also took the only subroutine that was actually classified (it did great circle distance calculations between any two points), and I externalized that so it could be kept in a separate file. That meant unless you were actually working on the great circle calculations, that code printout could be kept locked in the safe, while the now unclassified code that composed most of the actual Airfields Database could now be left out on the desk of the programmers without having to lock it up every night. The two full-time developers working on the Airfields Database were very happy at this outcome. Only thing is, when run on the Support system where we did our development, the printouts it created came out perfect. But when run on the production system, where all the real reports were ran, it generated an extra page break between each page of output. And if you modified the code to run correctly on the production system, it didn't work right on the Support system. We never did figure out that problem, at least not before I got reassigned to a different branch a couple of years later. The second big system that I'm happy to say I worked on was the OpenStack cluster that AT&T used. I was part of a small team, and the work we were doing was inside of Chef for deploying their code to OpenStack, but there was a lot of duplication between the various modules, and lots of duplicated modules. We ended up cutting their code base to one third the original size, and with our all of our self tests we built in for the CI/CD system, we made sure that all the code still worked and ran exactly as the original code did. The weird thing was that we never got any feedback from them as to whether or not they liked any of our changes, or if we had actually broken anything without realizing it. That was a total one-way street. The third big system I'm happy to say I worked on was the GPS OCX Next Generation Ground Control System for Raytheon. This had to control all of the GPS satellites currently in orbit at the time, plus all of the next-generation satellites that Lockheed was building. Again, this was Chef code, and we worked closely with the Raytheon developers to teach them everything we could about how to write Chef code, so that they could take what we taught them and apply that to all of their other code going forward. After six months, we did a test that simulated bringing up the entire datacenter (we were just spinning up VMs instead of running on real hardware), starting from everything being racked and stacked, and the all of our code took all of their core infrastructure code (also including all the OSes and databases, etc...) and deployed it and configured it for operation. They started off with that process taking three months to do manually before we got there, and our first full test run was successful and completed in three hours. We were ecstatic. Today, I work at AWS. Even just the tiny subsystem that I work on is bigger than anything else I've ever worked on before. It's a really challenging job, but also very rewarding. I honestly feel like I'm working with the best team of people I've ever worked with before. |
Circa 1984 (ish) I was in Australia and we didn't go looking for such wizardry .. it was easy enough to derive Great "Circle" paths about an oblate spheroid from first principals and, if required, weight the problem by wind strength, etc.
I was coding, at the time, for airbourne geophysical surveys at continent scale, so we were also pulling in IGRF models, normalising for diurnal magnetic flux, calibrating radiometric systems for air colum mass under craft | cosmic breakdown gammas from above, and all that jazz.
Was there anymore to your classified great circle code snippet than the correct geometric answer for a "not an actual sphere" .. or was the secret sauce just the exact series terms chosen and the order of computation in order to minimise error and reproduce consistent answers?
( I'm not asking for the revelation of the actual classified details, just curious about shape of the classified hole from the outside )