This post originated from an RSS feed registered with Python Buzz by Ian Bicking. Original Post: Rewriting and Refactoring Feed Title: Ian Bicking Feed URL: http://www.ianbicking.org/feeds/atom.xml Feed Description: Thoughts on Python and Programming. Latest Python Buzz Posts Latest Python Buzz Posts by Ian Bicking Latest Posts From Ian Bicking

I've been advocating lately to rewrite a CMS that we've developed, to move it from Zope to Webware. For various reasons we developed it with Zope -- the previous version was in Zope, all the other development was done in Zope, and I didn't feel confident about my opinion on Zope. Having gone through the process, I now feel more confident -- it wasn't a disaster or anything, but ultimately I was just working around the environment, and the parameters of the development pretty much excluded the possibility of leveraging Zope (RDBMS persistence with static publishing). These are a few of my thoughts as I try to justify this... notes to myself, but I thought I'd share the thought process.

So... the product is deployed and functional, and I've built various little workarounds to make due with the environment. But I know it could be a better product in the right environment (i.e., in a fully Pythonic environment). Because of the way it has been developed, changing environments would mean major reorganizing of the code (read: rewrite).

Rewriting perfectly working code is a hard thing to justify. It's not even a cleanup -- I haven't sabotaged the code, and I haven't lazily let cruft collect, and even if I did cleanup would be a very bad justification for code I wrote myself. Or, if it's a cleanup, it's an architectural cleanup, which is vague, especially since it's not my architecture.

I think there's two reasons to be suspicious of rewrites: it's risky, and it can lead to second-system syndrome.

Joel's comments on the riskiness are really an accusation of hubris on the part of developers; where they confuse I-can't-understand-this with this-is-bad-code. There's other parts too, like there's a lot of knowledge contained in that code, and you may not recognize it or appreciate its effect on the product. Or, in his summary:

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.

What does this say to me? It says: we must rewrite now! Because I do have more experience than the first team (which was a team made up of me). And if there's knowledge caught up in the code, that knowledge is also caught up in my brain. If this code needs a rewrite then it's best to do it quickly, because if I go then everything Joel says will be true about anyone who wants to rewrite it. (This is all the more complicated, because this version is itself a rewrite of someone else's work, so obviously I apply these ideas only when convenient :)

So... it's not the rewrite Joel is talking about. Which leads us to the second-system syndrome:

Designing the successor to a relatively small, elegant, and successful system, there is a tendency to become grandiose in one's success and design an elephantine feature-laden monstrosity.

This is a risk. And it's something I've done. My response to this is that we need to focus on one thing -- in this case the programming environment -- and resist making any other changes in the process. Which means no added features, no change in the database schema, no changes to the URL schemes or screen layout, and a very clear target: something that is indistinguishable from the current application. In reality there will be some changes, because I would revisit every piece of the system, and some parts are forgotten and changes will occur to me. But fixing those things isn't in the plan, and if I realize I'm doing that, then I've already spent too much time distracted from my main goal (reimplementation) and I should check myself.

Sadly, this means that the resulting program will have no advantages over the original program. The time invested will seem like a waste from the outside. But then, that's always the nature of refactoring -- and even though this involves rewriting all the code, it's really just a kind of refactoring.

It's still to be seen if I can actually convince them of this all...