Hiding From Legacy Code
My career history hasn't been what could compare to the typical technology path. I started out in desktop publishing and slowly made my way through the ranks learning all about this crazy world of web development. True, I had been into computers and had written a quite a few programs in BASIC and even done a little Perl and ASP scripting, but I never took it seriously in any real way. I certainly never thought I'd make a career out of it.
The point, is I never did the support desk thing (this definitely seems like something a majority of programmers and IT guys did).
Hell, I never even had to maintain an existing system until my third year of working. I spent the majority of my career, up to the point I first encountered a legacy system, working with teams on new systems. This shouldn't imply that I was unfamiliar with code written by other developers; I've always made it a practice to use existing code whenever possible. I just hadn't had to maintain one for a while. Obviously, my life was puppy dogs and rainbows year round.
Today I generally view maintenance work as something to be done with care. If a system is in production, and I didn't write it, that system should be handled with respect when making modifications. Refactoring is strictly off limits unless a) I know the code inside and out and significant pain of future updates is sufficiently unbearable, or, b) there's an immediate need to make the change along with the time to get to know the system. There's obviously exceptions but, for the most part, I need to know the code ahead of time and there has to be some benefit for the change.
There's a new thought I've been struggling with for the last couple weeks; all programming is maintenance programming.
Bill Venners: You say in your book, The Pragmatic Programmer (Addison-Wesley, 1999), that "programmers are constantly in maintenance mode." Why?
Dave Thomas: All programming is maintenance programming, because you are rarely writing original code. If you look at the actual time you spend programming, you write a bit here and then you go back and make a change. Or you go back and fix a bug. Or you rip it out altogether and replace it with something else. But you are very quickly maintaining code even if it's a brand new project with a fresh source file. You spend most of your time in maintenance mode. So you may as well just bite the bullet and say, "I'm maintaining from day one." The disciplines that apply to maintenance should apply globally.
Andy Hunt: It's only the first 10 minutes that the code's original, when you type it in the first time. That's it.
The above hits especially hard now that I'm a full time freelance programmer. I've been BUSY lately (which is why I haven't posted much in the last week) working on "touching up" existing sites. There's a crap ton of work out there for a programmer who can dive into an existing codebase and make changes.
The crimes against humanity I've witnessed in some of the code I've looked at in the last week are just awe inspiring. There is code out there that was created a few years ago, that have just been edited and changed and modified and customized (and on and on and on) by too many programmers with too different design philosophies that now the code could make your eyes bleed. It's kind of sad when you think about it.
I've mentioned before about the importance of code structure and formatting and I think it bears repeating:
On the other side though, we also have to write code on behalf of our clients. We give them code that they paid us to do so it’s pretty much a foregone conclusion that the client is going to go through the code. If we hand them crap they’re, obviously, going to think we suck. That’s no good for anyone.
It seems like such an obvious thing to write good, clean and well formatted code, that it’s a little surprising how much bad code is out there.
It's kind of depressing if you think about it; all the half hazard changes being done to an existing codebase starts a snowball effect of charges escalating and costs raising. Put simple; the more mods that are done over time the more cost gets associated with subsequent updates.
To help alleviate this for my clients (at least) I think it's important to work within the existing formatting and coding style for any legacy code I touch. It's definitely a pipe dream to think everyone should (or would) but, for me, it seems the least I could do.
Email
Twitter