Comments on: Total Loss http://blog.qualityaspect.com/2006/11/21/total-loss/ Lidor Wyssocky's Blog on Optimizing Software Development Fri, 16 May 2008 15:50:10 +0000 http://wordpress.org/?v=1.5.2 Comment on Total Loss by: Vinyl http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-36787 Thu, 06 Mar 2008 23:57:36 +0000 http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-36787 Thank you for the wonderful article. You've given me something to think about. Thank you for the wonderful article. You’ve given me something to think about.

]]> Comment on Total Loss by: Angie http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-36744 Wed, 05 Mar 2008 20:59:19 +0000 http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-36744 I think the most important step is to be realistic in what you can and cannot do. I think the most important step is to be realistic in what you can and cannot do.

]]> Comment on Total Loss by: Home Developers Repair Maintenance http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-34853 Mon, 04 Feb 2008 13:53:09 +0000 http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-34853 <strong>How To Repair Bad Credit By Refinancing Your Home Mortgage</strong> 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... 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…

]]> Comment on Total Loss by: ade http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-16999 Sun, 10 Jun 2007 21:43:25 +0000 http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-16999 If you are looking for a <a href="http://www.worldtopix.com/used_cars.html" rel="nofollow">used car</a> keep a few guidelines in your mind and you could just drive away with a great car....<a href="http://www.worldtopix.com/used_cars.html" rel="nofollow">read more</a> 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

]]> Comment on Total Loss by: Bill http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-16182 Fri, 25 May 2007 19:04:39 +0000 http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-16182 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. 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.

]]> Comment on Total Loss by: Mike-O-Matic » Efficiency isn’t Why We’re Here http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-4662 Mon, 27 Nov 2006 16:10:42 +0000 http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-4662 [...] Lidor&#8217;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? [...] […] 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? […]

]]> Comment on Total Loss by: warpedvisions.org » Blog Archive » Code reuse is like a dirty sock? http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-4595 Sat, 25 Nov 2006 23:51:15 +0000 http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-4595 [...] Code reuse is like a dirty sock? Another explanation for the programmer&#8217;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&#8217;re doing (and how both work). [...] […] 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). […]

]]> Comment on Total Loss by: jk http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-4574 Sat, 25 Nov 2006 10:01:26 +0000 http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-4574 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. 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.

]]> Comment on Total Loss by: Lidor Wyssocky http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-4489 Wed, 22 Nov 2006 20:37:01 +0000 http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-4489 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 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

]]> Comment on Total Loss by: Jeff Staddon http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-4485 Wed, 22 Nov 2006 18:05:26 +0000 http://blog.qualityaspect.com/2006/11/21/total-loss/#comment-4485 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. 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.

]]>