Summary
The hardest part of writing a book is discovering that you can't read it any more. That's when you get scared.
Advertisement
A week ago, a friend of mine chided me for not having blogged my book 'Working Effectively with Legacy Code' (WELC). It was easy to tell him "No, I'm just not good at the self-promotion thing" but, thinking about it, I realized that there was also a deeper reason. The sad truth is, that the writing process got me to the point where I just couldn't write about the topic any more. I also could barely read what I'd written. You can only read your own words so many times before you just don't see them anymore. I remember talking to Martin Fowler at a conference just before his Refactoring book came out. I asked "So how's the refactoring book going?" and he answered with something to the effect that he couldn't look at it anymore. That's pretty much how I felt up until a month or so ago.
Anyway, I'm at the point now where I can read it, and I am going to do a lot more writing and talking about the topic, because I feel it is an important one even though it is hard to discuss. After all, who wants to talk about legacy code? What is it? Ancient COBOL? CICS? K&R C? Well, to me, legacy code is code that makes us say "eeeww... who did this?", even when the people responsible may be ourselves, days, months or years ago before we knew better. In other words, legacy code is code that we don't understand, code that is hard to work with.
The topic isn't as "cool" as MDA, .NET programming, or AOP. We don't get to imagine some pristine technological world where we are starting from scratch and all the problems get swept aside, it's just the sort of work that people can do day-to-day in existing systems to make them more pliable and easy to work with. Sounds like refactoring, doesn't it? Well, refactoring is involved, but most of what I've been writing and talking about is how to get portions of code under test so that you can refactor it or add new features safely.
A lot has happened since the book was published late last year. Like I said, I've had that period where I tried not to think about the topic, and I had a long period of self-doubt (when you can't even read your own words any more, it's very hard to convince yourself that what you've explained things well enough). Regardless, the book seems to be selling well and I've received some great personal notes in email (thanks). When I was at SD West a few weeks ago, during one of my visits back to the conference bookstore, the book seller said "Hey, I think you are my top seller." The next day the book sold out. The reviews on Amazon have been great. The book has been floating pretty high in the sales rank for a while. It dips down and then soars again, unpredictably. Brian Marick shocked me by calling the book one of the most influential computer books of the past ten years, JavaRanch gave it ten horseshoes and Gregory V. Wilson said, in a review in C/C++ Users Journal, "Working Effectively with Legacy Code is quite simply a great book. I've folded down more corners on it than any other book I've read this year..."
So, that's all the shameless promotion I'll do for the book here. It's hard to do because I see the little things I would change now, things I've learned since then, however I feel that I do have to push the book a bit. The term "legacy code" isn't very sexy and I want to make sure that the book gets in the hands of the people who need it the most.
Over the next few weeks, I'll be writing articles about various techniques that can be used in legacy code and I'll link them from here.
If you want to discuss issues related to the topic, feel free to post them here or join the WELC yahoo group at http://groups.yahoo.com/group/welc/
I'll be speaking at SPA2005 next week in Bedfordshire, UK on a completely different topic (coaching) but I am looking forward to side discussions about legacy code. Please say hi if you are there.
You'll doubtless be pleased to hear that the book arrived on my doorstep yesterday. I've only read a few pages of the 'Monster Methods' so far, but it looks good.
You say that the topic isn't cool but when you bear in mind that the majority of programmers spend the majority of their time with legacy code (often of their own making) then I think you've hit on a massive potential market that needs all the help it can get.
On the subject of coolness: Not at least because of my day-to-day experience with "legacy code", my main private computing interest at the moment is actually aligned with my professional interest: learning how to evolve code over time (I think it said something about that interest of Mikhael Feathers on the book bio, as well). This also fits well with my interest in refactoring, patterns, etc.
So, the issue of evolving code over time (regardless of its existing state), is something that can be very cool, indeed, I think. :)
Great book, by the way. :) (It was recommended to me by Dave Astels - I had given him some positive feedback about his blog (http://www.artima.com/weblogs/viewpost.jsp?thread=71730), and in the mail exchange, he recommended the book.) I'd say it's just what the doctor ordered. :)
I'm late in replying, but I've only recently received a copy of your book.
Wow.
It's funny, I thought I knew a thing or two about working effectively with legacy code, including putting old, tangled code under test, but reading your book makes me feel like a beginner again - in a wonderful way! Thanks for sharing your experience!
Previous Topic
