Friday, Debtember 10, 2021
Working on legacy projects
The Corporate Overlords have assigned me to maintain “Project: Bradenburg.” It's a project my department is responsible for, but I never worked on it. It was written by fellow team member JC who left last year, and the person who was supposed to maintain it (he was assigned to our team shortly after JC left) also left this year. So now it's my turn.
Woot! Legacy code!
Unlike the rest of our code base, “Project: Bradenburg” expects to run on a modern 64-bit Linux system. Okay, cool! I get to learn about running Linux VMs on an Apple Mac book (only took two days, and constant reminders to myself not to throw the laptop across the room, to get the VM installed and running).
Then I attempted to build the system, and that's when I learned the Linux system I'm running is a bit too modern. It took some hacking to get the code compiled, and I'm concerned about how best to integrate the changes I have with the build system.
I'm also learning why people hate
I've never really got the hate,
because I never found
make all that difficult to use
(especially GNU Make—I find it quite nice to use).
But diving into “Project: Bradenburg” really has me questioning JC's … um … design asthetic when it comes to
I was able to replace six
comprising a total of 700 lines,
Makefile of 197 lines,
150 of which comprise the dependency list
(automatically generated—leaving 47 lines to do the actual building).
I'm sure the
Makefile will grow a bit
(to cover building a release versus a debug build)
but not 500 more lines.
Another thing I'm working on is finding out not only who uses “Project: Bradenburg,” but how they're using it. I know the Corporation uses it, but I do know that JC was working with our Corporate Overlords to have it used elsewhere. I want to rip some stuff out if it (like the internal stack tracing mechanism) but I first want to know if anyone uses the stuff I want to remove.