Keith Casey has an interesting new post to his site looking at a common dilema among development groups - whether refactor or rewrite is a better option for the state of the current codebase when it comes time for a change.

In software development, we're spoiled. We can write a single line of code and do some interesting things. If we add a framework, that single line of code is backed up by thousands.. and can do even more impressive things. [...] I can't tell you how many people have pitched me to "rewite web2project using [framework x]." At first pass, it sounds like a great idea. We can lay the foundation for doing things "right." We can use the latest and greatest tools, technology, and concepts. Even better, we don't have to figure out all that old crappy code! It's open source so it's free anyway. Everyone wins! How many times have you looked at an application and thought "I could rebuild that in a weekend!"

He points out the "seductive" nature of this kind of thinking and some of the things that it can hide from your immediate vision. These are things like: the lessons that were learned and implemented in the current code, catch up vs new development on the project and the possibility of "killing the community" as they'd no longer know which part of the project to contribute to.

He suggests instead of worrying about a rewrite, that development groups worry more about managing technical debt in their applications and reducing that piece by piece instead.