Total Loss
Used cars. That’s what’s on my mind these days. My wife and I decided that we need a second car. But judging from the time it takes us to find one, I’m not sure we are really serious about it. Well, we are, but here’s the thing…
You see, I’m just too paranoid to put my money on a used car. A car someone else drove. A car someone else took care of. Did the previous owner treat the car well? Did he change the oil on time? Was he careful not to push the car to its limits? And how many owners did the car have anyway, and who were they? I just don’t know, and this uncertainty makes me think twice (OK maybe it’s more than twice) before I place my bet on that car (or another).
Cars just don’t get better over time. You know that. And in the wrong hands, it might get even worse. So, how can I possibly buy, not to mention drive, something like that? I know, everybody else is doing it, so why can’t we? We can always have the car checked before buying it. That’s not the 100% guarantee, but it’s the least we can do.
***
Used code. Used code is a lot like a used car. I’m really paranoid when it comes to used code. Code someone else wrote. Code someone else took care of. Did the previous owner of the code make sure the code works as expected? Did he write the code such that I can work with it as needed? And how many owners did that code have anyway, and who were they?
Like cars, code cannot live forever. It can be used for years, but just like with cars, as time passes it costs more to maintain and keep in a good shape.
Everyone knows the term “code decay”. But not everyone realizes it is a natural tendency that affects every piece of code. That is not to say that we shouldn’t write quality code. The better the code we write is, the more resistant it will be to this law of nature. Just like a well-treated car lasts longer than a neglected one.
Code should be written well to begin with. It’s also important to have routine maintenance on your code (refactoring, remember?). But as the case is with used cars, you should follow some guidelines to ensure you won’t find yourself with an unusable (and maybe even dangerous) wrack.
1. Don’t assume your code will live forever. Do what ever you find reasonable to write it so it lasts. But always be prepared to say “this code has served me well, but it’s time to let’s go now”. Hanging on to your code after that point means spending a lot of money on recurring (and futile) repairs.
2. Be suspicious. Being somewhat paranoid has never hurt anyone. Before you take a piece of used code under your responsibility, make sure you will be able to safely work with it. If the code you have to maintain looks like a car you wouldn’t even take for free, consider the option to go for a newer model.
3. Look under the hood. When you are going to work with a third-party component, it might be useful to have a look at its code first. Not every vendor will allow it, but if you don’t ask, you will never know. A short glimpse at the code will help you know if you are dealing with a component that has a future or with a component with a tragic past.
***
A colleague of mine once said that every piece of code should have an expiry date on it, after which you have to throw it away. I don’t know if I would go as far as that. But it might be nice if every piece of code would have a warning on it saying, “would you drive this code if it were a used car?”
November 21st, 2006 at 2:02 pm
Nice perspective–never quite looked at it that way. I know I’ve always hated working with “used code”, always preferred starting up from scratch (or reasonably close to it at least.) Now I have a more tangible excuse :)
November 21st, 2006 at 5:05 pm
Really interesting. Unfortunatelly, source code, as opossite to a car’s spare parts, does not get rusty. It is somewhat subjective, but i do prefer to use old-and-tested code rather than shiny-and-fresh code. Source code does not get old: it (generally speaking), matures. At least that’s my theory; give me 5 years and i’ll tell you my new opinions :)
Cheers :)
November 21st, 2006 at 7:24 pm
Very nice, your post is a good counterpoint to Joel Spolsky’s thoughts on rewriting code:
http://www.joelonsoftware.com/articles/fog0000000069.html
November 22nd, 2006 at 4:05 am
Oh no, not another analogy between manufactured products and software. Creating software is a design process and once released, the software absolutely does not fatigue. If the hardware is available it will keep running forever, date-related bugs aside. Yes, *changing* software will result in degrading quality, but the changed software is not the same item, which is why we use version numbers. Your car doesn’t come back from a service with a 2.0 badge does it? And Joel is right - new code is worse than old code as it hasn’t been through the maintenance and bug-fix cycle yet. You think Vista will be more secure than XP? I doubt it because Microsoft rewrote the network stack and there are inevitably exploitable bugs in there. Yes there are pathological cases but in general the same goes for all new vs. old software. So please, enough of these fallacious analogies between software and physical products.
November 22nd, 2006 at 5:58 am
+1 to Neil
November 22nd, 2006 at 10:05 am
Interesting, but flawed. I strongly disagree with the concept that code ages. The reason code “gets old” is simply bad maintenance practice. New code is expensive and usually buggier than old code. It should be avoided if at all possible. It’s far more cost effective to maintain a code base than to re-create it over and over. There is only one reason to replace code—if the technology changes too much. (i.e. it won’t play with other technologies, or the personal or hardware isn’t available, lacks the tools to solve new problems, etc)
But, there are some tricks to good maintenance. To make a system “ageless” you must never “patch on” changes to the system. By never, I really mean NEVER. If you put in just one patch to avoid a particularly painful re-factoring, that patch will spawn another patch and another and another. Before too many years (or months in worst cases) a complete re-write becomes the only option.
All maintenance changes must be seamlessly integrated into the existing system. If the integration requires changing the system architecture–swallow the pain pill and do it. If you do this, your system simply will not grow old. An added bonus: if you stick to this disciplined maintenance approach, porting to a new technology will be far easier since the system architecture will clearly reflect the current business domain/requirements not a muddled mess of different versions of past requirements.
November 22nd, 2006 at 12:37 pm
People, people… of course you are right. Code which is left alone does not age. Software is not like a car, which won’t live forever due to physical laws.
But, you all seem to agree that maintenance (that is bad maintenance) changes the picture. And that’s the point I was trying to make.
If you get a piece of code and you assume it was well taken care of, you might be… well, wrong. That’s why you have to check. Saying that any piece of existing code is better than a new one doesn’t make sense. If, for example, the previous owners of the code did a lousy maintenance job, you might end up with code that requires you to invest weeks of work for each small change. You can try refactoring that mess, but this is not always possible or cost-effective.
Joel’s article and your comments are 100% right in an ideal world where most of the code out there is reasonably maintained. I’m not sure this is the reality we all work in. But in any case, it’s better not to assume anything and just make sure you check the status of the code before making a decision.
I don’t like black and white rules. Unlike Joel, I try not to use phrases that begin with “Never…” or “Always…”. Just keep your mind open to the option that sometimes a rewrite is better than refactoring.
Of course, you should do it wisely. Don’t wake up one day and throw away 500K lines of code. Do it incrementally and with proper safety nets. But keep in mind that this is a valid option.
Lidor
November 25th, 2006 at 2:01 am
A better analogy would be a “used house”. People don’t ever call the house a used house, but, it is. Over time, a house tends to accrue “improvements”. Maybe the fixtures get replaced, or windows get installed. Maybe the house gets its floorplan modified. Maybe the laws change, and when you do a modification, you have to do a whole series of changes to comply with the law. Generally, these are permanent changes. That’s similar to software — if you add it, you have to live with it.
(There are things in houses that wear out, but a lot of things last 10+ years. That’s what’s like software.)
If the previous owner had some sense, the modifications will generally not stand out. They’ll fit in, pretty much, invisibly. They might even repair defects in the original design, without adding features.
Most houses, however, don’t fare so well. They get ugly additions, or trendy “remodels” that don’t really improve things. Maybe they don’t degrade the house, but, they may not really help it either. Some additions, however, really damage the house, by messing with air flow, creating new areas to clean up, taking away from the garden space, or making the house look ugly.
A few years back, the popular remodel was to install ceramic tile floors everywhere. Those floors are cold, hard and basically unpleasant to step on. It’s an upgrade that seemed like a good idea at the time, but will eventually be an expensive liability once people realize the problems. Worst of all, they last forever, making you feel like a fool if you dare to remove it.
I’m sure we’ve coded a ceramic tile floor into some project at some time or other.
People mocked me (and continue to mock me) when I express a preference for vinyl flooring in the bathroom, simply because it’s the warmest non-carpet material.
I can sometimes sense derision when I tell people I still use Perl in addition to other languages. I think Cold Fusion has a lot of good ideas, too. I said the same for Lisp, but that gets some respect these days. Lisp is like the gas range — companies keep trying to make new rangetops with fancy new technology, but people keep returning to gas or propane… because they want to cook with fire.
November 25th, 2006 at 3:51 pm
[…] Code reuse is like a dirty sock? Another explanation for the programmer’s illness, not-invented-here, code reuse == used car. This is superstitious horse shit, on both accounts: code and cars reuse fine, if you know what you’re doing (and how both work). […]
November 27th, 2006 at 8:10 am
[…] Lidor’s blog had an interesting post the other day about how code ages over time. He urges programmers to treat inherited or older code suspiciously, and to not rule out rewrites. Used code. Used code is a lot like a used car. I’m really paranoid when it comes to used code. Code someone else wrote. Code someone else took care of. Did the previous owner of the code make sure the code works as expected? Did he write the code such that I can work with it as needed? And how many owners did that code have anyway, and who were they? […]
May 25th, 2007 at 11:04 am
There is a way to obtain a used car’s “story” - simply visit Carfax.com and purchase a vehicle history report. You’ll be able to see how many times the car was titled, where, when, mileage at titlement as well as any accidents that were reported on the car. In addition to an inspection by a qualified mechanic, this is about the best one can do.
June 10th, 2007 at 1:43 pm
If you are looking for a used car keep a few guidelines in your mind and you could just drive away with a great car….read more
February 4th, 2008 at 5:53 am
How To Repair Bad Credit By Refinancing Your Home Mortgage
One of the best ways to repair your bad credit is by refinancing your home mortgage. The difficult part is finding a lender for your home mortgage since your credit history is not good. Forget about the banks and other financial institutions, they will…
March 5th, 2008 at 12:59 pm
I think the most important step is to be realistic in what you can and cannot do.
March 6th, 2008 at 3:57 pm
Thank you for the wonderful article. You’ve given me something to think about.