How to Program in a Bureaucratic Environment

Hello World!

Lawrence Livemore Laboratories is a wonderful place to work, but it can be somewhat bureaucratic. This is frustrating because it is also working on some of the greatest science being studied in the world right now so it would make sense for it to be supported by equally good code and management, but it is a federal beurocracy so that's not how things work. This is frustrating for many reasons. For example, one time they mailed my check to the wrong place and I ran out of food. However one of the biggest issues I have had to deal with is the code quality itself.

Migrating Java 8 to Java 11 is difficult on its own. There are three main issues. The first thing is the libraries. In Java 11 you need to import some libraries from jar files because they are no longer part of the included Java library. The second thing is the signatures. Some of the code went through signature changes, such as the vector class and my boss and I have been going through the code changing around the signatures. The part that is hardest, and in my opinion the most fun, is the unit tests. Writing unit tests for code that works is much for fun than writing code for pre-made unit tests! You just have to pass in a couple things to the code and see if they match the expected responses.

The Java codebase that I am working on is the interface between the scientific researchers, and the laserbeam. This codebase began its life as Ada. Ada is a language developed by the United States Department of Defense, designed to be better than C++ for writing weapons code. It’s quite a bit different than Java, and a lot was lost in the translation from Ada to Java. So that’s why there are currently five empty functions that return null, which cause huge errors when deleted, and a comment at the end of a class informing everybody who might be curious that it is the //end of the class.

In addition, rather than using Git or GitHub, Subversion, a differnt type of version control is used. As far as I can tell, Subversion has no advantage over Git, they just started using it and never wanted to migrate. It makes code edits take a very long time and there are just random chunks of dead code lying around. The code is so old that some of the copyright dates are from before I was born, and since it was developed before test driven development became a thing, there are very few unit tests and most of the codebase is not covered by unit tests.

I’ve also learned that when a function or a class is no longer needed, it typically isn’t deleted. This is because you’d have to test it, which takes time. BUT WAIT! I hear you say — if you’re deleting stuff, you’re just going to have to run the integration tests, and it’s highly unlikely that they’ll need to be altered significantly, if the code really does need to be deleted. Isn’t that okay? Apparently not! They really just don’t like us changing stuff in our code. I don’t understand it, but that’s how it is. So there are whole files of dead code, just lying around! It’s a mess.

I spoke to one of the lab programmers and he said that the reason for this is that with code, need to sacrifice either cheapness, speed, or quality. LLNL had decided to sacrifice quality. This then led to fewer people wanting to work as a programmer in the National Ignition Facility, which leads to worse code, and so on.

There is no perfect solution to working with a bad codebase, but the way I am currently getting through this is by looking at the code I'm working in as a natural system. If you are writing code to predict the orbits of the planets, you don't complain that the planets have oblong orbits rather than circular, you just work with them. Similarly if I look at the LLNL codebase as a natural system that I need to work within, it is easier to cope with the fact that I am working with some really bad Java.

May you be ever victorious in your future endeavors!
M.E.W