I hope, I'm not the first one two say this but I totally stand firm behind my wisdom! It's usually "legacy this" or "legacy that" but the general terminology lies around the concept of trying to work your way around existing source code.
When the term "legacy system" was first introduced all it meant was that the system had been there long enough that the owner/maintainer didn't want to replace it. But recently I've been hearing the "L" word a lot around my colleagues and the code they are talking about is from our last release which was only a couple of weeks ago. I keep thinking to myself, "Code that young can't be legacy, right?"
Truth of the matter is AS SOON AS YOU CHECK YOUR CODE INTO REPOSITORY, it becomes LEGACY (You have a repository right? Don't make me force you to take the Joel Test!). Little disclaimer here, of course having a repository also means you use it frequently - if you don't, again, please please PLEASE check your code in frequently and in small increments; it's a good practice and you'll actually see your progress easier.
You're in total denial if you don't believe me; how many times have you thought "What the hell does this method do?" or "How am I supposed to use this API?" Off the top of my head, here is a very short list of ways any code becomes legacy:
- Some guy wrote it 7 years ago, the day before he was let go.
- You HACKED it for the last release in order to fix your bug, but now, it doesn't click anymore.
- You thought you had some progress last night and decided to check it in. This morning, how ever, you think you have a better solution but it's so damn hard to retrieve to the last version and you sit in your cube, beingmiserable and all... You get the idea.
Only defense you have is to be aware that one way or another your code will become legacy and you can't stop that. Live by this rule for the next day, week or month and let's see how your life changes.
0 comments:
Post a Comment