Dealing with the Lame Duck Code Base

I wear my green "Test First" wrist-band to remind me that when I write code, I must write the best code I can. It doesn't matter if the code is lame-duck or not. It doesn't matter if it is experimental or not. It doesn't matter if I am in a hurry or not. What matters is that I maintain a professional attitude about writing code.



In martial arts, it is the custom to bow to the dojo (the room in which you practice) before entering and leaving. This is a ritual of respect for the discipline that you are learning. It is a way of saying: "What happens here matters." You may never have to use the disciplines you are learning; indeed you HOPE you never have to use them; but learning them matters.



When you put your fingers on the keyboard and write code, it matters. It matters because you are a professional. It matters because THIS IS WHAT YOU DO. It matters because the disciplines of writing good code are hard to foster and easy to lose.



So I wear my green test-first wrist-band as a sign of respect for the discipline that I continue to foster.

I was speaking with a manager recently about a legacy codebase. It hadn't been deployed yet, but we knew it was legacy. He told me that he couldn't find anyone who would work on it other than the original developer. None of the other team members wanted to work with such code. My reply was that they were obligated as professionals to do the best that they could with it if their work on it would serve the best intersts of the company. Besides, it was not for them to decide whether they would work on it; that decision belonged to the manager. Anyway, I don't know anyone who is excited to work on code that would be great to have as a reference while reading your book, Michael. ;-) Now that I think about it though, maybe we should be. When opportunity knocks, we should answer the door and welcome it.





In late 2000, I was working on a small team building the framework to be used for the application. We had surveyed the various legacy systems, looking at the common services that the new application would need to provide. At the beginning of January 2001, we started to build some of the services, starting with language-handling (I won't bother with the details why standard Java wasn't good enough in that situation), and classes to hide the complexities of dealing with JDBC. As my blog entry states, the decision was made in February to move to the COTS solution, but we were still allowed to work on the framework. It was difficult, knowing that your work seemed useless, however we kept going.



In July 2001, another group heard about what we had and asked to use it. I left that project in August 2001, but caught up with the same team members again in Oct. 2003 when I joined another project at that client. Lo and behold, there was the language and SQL framework code in daily use, almost untouched from its original state in 2001.



So had we just abandoned it the code, two other teams would have had to reinvent the same concepts. We're quite proud of the SQL-wrapping code, especially after we found out about Spring and discovered that their code was almost the same. (Though we had named parameters - rather than positional ones - in 2001, while Spring is just introducing them with the impending 2.0 release!)

Your notion that you just don't know if code will truly be abandoned resonates with me... I recently wrote a blog entry ( http://mayford.ca/blog/?p=21 ) about a project that originally was to be a custom-built Java application turned into a COTS fiasco.In late 2000, I was working on a small team building the framework to be used for the application. We had surveyed the various legacy systems, looking at the common services that the new application would need to provide. At the beginning of January 2001, we started to build some of the services, starting with language-handling (I won't bother with the details why standard Java wasn't good enough in that situation), and classes to hide the complexities of dealing with JDBC. As my blog entry states, the decision was made in February to move to the COTS solution, but we were still allowed to work on the framework. It was difficult, knowing that your work seemed useless, however we kept going.In July 2001, another group heard about what we had and asked to use it. I left that project in August 2001, but caught up with the same team members again in Oct. 2003 when I joined another project at that client. Lo and behold, there was the language and SQL framework code in daily use, almost untouched from its original state in 2001.So had we just abandoned it the code, two other teams would have had to reinvent the same concepts. We're quite proud of the SQL-wrapping code, especially after we found out about Spring and discovered that their code was almost the same. (Though we had named parameters - rather than positional ones - in 2001, while Spring is just introducing them with the impending 2.0 release!)

If the code base doesn't matter, why does the company invest time/money in it? If it is only because they haven't got a clue what they are doing, then find another job. But if it really is important you do what you are doing, then it isn't really a lame duck, is it? Do you really want to build something your great-grandchildren will use (and probably swear at) or do you just want to do something that makes a difference?



In this situation, they probably haven't allocated as much development effort as they would have otherwise, so keeping up is probably going to be more of a challenge than if you were working on something shiny and new. So enjoy the challenge. If everyone is bored, then that is a bad sign. Move on, or spend time sharpening skills. If management knows they have more developers than they need, you won't be around long.

This situation is very common when you are involved in an acquisition. When the parent company and the target are in the same market space, the goal of the acquisition is to transfer the customers to one product. The product to be retired must be maintained during this transition period. This is a true lame duck situation. The one bright spot is that your future efforts will be in the same domain. What you learn today, can be used tomorrow. The challenge is to work on the old product while the next gen product is moving ahead.

I managed a team of developers in which we would work feveriously on the latest, greatest business venture, only to have it shelved a month later. This became a way of life. I preached often that our work wasn't in vain. We were learning about programming, we could quickly pack up from one project and set down on the next, we were agile!



It took its tole though. I saw that tired look in each one of my developer's eyes when our boss would come in really fired up about the latest venture. We got past it and acted like professionals but I bet that we didn't perform as well as we would have had we believed in it.

Remember all those Y2K [?] bugs? Those happened because the programmers all "knew" that they were writing code that wasn't going to last. Except it did... until it was eventually was replaced by Y2K [?] remediation.

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 thiscode 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 aor not: it may or may not be replaced. But if we treat it as a, we becomeourselves; 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: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