Dealing with the Lame Duck Code Base

I don't know about you, but I like working on things that matter. When I look back and remember the times in my work life when I've been most demoralized they've been when I was asked to work insane hours to finish something that will never be used. There was the time, in grad school, when my friend Maria and I worked insane hours to meet a deadline after the rest of our team had defected. We had to finish a piece of OS code, and we knew the professor wasn't even going to look at it. Then there were the times when I've had to work straight through Christmas up to New Year's because something "has to be done before the end of the year" even though it wasn't going to be used until, say, March. There are also the times that I've worked hard on code that I knew would never be used because of a pending business change. In one case, I had to do detailed design and coding for a product that everyone knew was about the be significantly contracted or cancelled, but we had to go through the motions. It was just the job. The list goes on and on.. I don't think I've been in blacker moods than when I've been in one of those situations. I like code to matter. Maybe this is just a personal quirk, but I don't think so.

A few weeks ago, I was talking to the manager of a team I was teaching. He was eager to use some of the legacy code techniques in their application, but he has a dilemma. The code is on borrowed time. Within the next two years it is going to be replaced. That is the current plan, at least. My first question to him was "does the team know?" And he replied "yes" the team does know, and he mentioned that he could already see quality problems. The programmers were clearly asking themselves why they should work so hard on this lame duck code base, this code base that is going to go away.

Why indeed?

Well, we can look at it rationally. I think anyone with some experience in the industry has seen cases where "the plan" for some big code base changes; it's very common. Sure, you can cut corners, but when it's obvious that the big replacement isn't going to happen, well, all you can do is look at the mess you've created and cry.

So yes, there is a rational reason why code always requires your best effort, and that reason is: we never know what's going to happen next. Things change. The code you think may be discarded could end up being used. Systems have lives of their own. A piece of code that you think is insignificant could end up being used for years, decades, and for many of us now, perhaps centuries.

The truth is, we can't really tell whether a code base is a lame duck or not: it may or may not be replaced. But if we treat it as a lame duck, we become lame ducks ourselves; we wait for the new system, and in the interm, we aren't really programmers.

So, is that argument enough? Enough to convince you that code always requires your best effort?

Maybe it is. I hope so. But I don't think that argument touches the core of the issue. The core of the issue is personal. For me, it has been a long haul, but I find now that I am happiest when I pay less attention to whether code matters to someone else and more attention to how it matters to me.

And: I can always make it matter to me.

Yes, I still feel cheated if I work long hours for something inconsequential. There is no getting around that, but put hours aside.

If I'm working a nice human-friendly schedule and I feel that the code will be underutilized or unused, I can still choose to use it as a learning opportunity. I can still do my best. Every day is a chance to do something in code that I've never done before, or to find a new way of doing things. Even the simplest problems are fertile ground for learning if you reflect enough upon them. And, in the end that is the richest part of this work. The other stuff, well, that can be ignored.




!commentForm