Jeff Eaton posted a couple of links on Twitter (one, two) yesterday about refactoring/rewriting programs. And I’ve run into several issues related to that lately, so I thought I’d write about it a bit.
This isn’t exactly the first time I’ve had to work with other people’s code, but it’s the first time I worked with code belonging to people who had my exact position, rather than students or half-timers. (Relatedly, this is probably the first time I haven’t been really the first person doing my job since I was an administrative assistant over a decade ago. I’ve gotten used to decidedly forging my own path…which is probably worth another post sometime.) And so where I might have gleefully thrown out, rewritten, or made obsolete the work of others in the past, I’m being more cautious now.
As an aside, it probably matters that I have known one of my predecessors for quite a while, before he even worked at Evergreen, and I respect his skills quite a bit.
Three times in the last week I’ve run into things….
One project we will be tossing out entirely and giving to another group on campus. It probably never should have been done by our group to begin with, although apparently it made sense at the time. On top of that, it’s in a fairly old version of Ruby on Rails, which I don’t know, and an older version that the “Rails guy” would prefer to work with. We had a mysterious failure, which no-one can explain, or to be honest otherwise it probably would have been left alone even longer. Now we’ll leave it to limp along while we wait for another group’s project that’s a prerequisite for handing it over.
Curiously, the public-facing side of that project is still likely to be ours, because it’s some XML that gets fed into our content management system. So in theory that could get left alone, since that part still works just fine. It’s just the content-editing part (not in the CMS, shouldn’t be in the CMS) that’s broken.
But that leads to the nut of my other problems. Without getting too much into the technical details, I keep finding bits of code that seems to not use the CMS’s features very well, and are incomprehensible to me as well.
I am even more convinced of the importance of code documentation. If a half a decade’s worth of tinkering has good notes about what everything does, how it works, why some oddball thing is there, then I’m more likely to be able to continue tinkering or refining. If I can’t make heads or tails of what’s going on, and it feels wrong intuitively, I’m more likely to throw up my hand and throw out the code. It may well be that some of the strange bits are to work around issues with the CMS that have been fixed since that code was written. But I can’t tell, especially since this CMS is new to me.
And because it’s new to me (and for lots of other reasons) I find myself struggling just to work with the CMS as it is, without taking into account these bolted-on chunks of code. (PHP inside the CMS. I don’t even.) So I start wondering about tinkering versus tossing at the next level up: do I want to spend the next X years of my life with this particular CMS as my main responsibility? Do I advocate for change or put the effort into getting the best out of what we have?
