Don’t rewrite Your Application | Hacker News Reader

Don’t rewrite Your Application

javacodegeeks.com

I'll agree that they are often a very bad idea. But there are advantaages:

1) Writing the same code a second time often results in cleaner, more efficient code that is easier to maintain. If you don't believe this, write a small app. Then start from scratch and write the same app again, from scratch, without looking at the other. For further proof, do it again.

2) Some code is just not maintainable. If you can't test it, you can't change it without fear of breaking something. I usually do my best to write tests for the old code, but sometimes that's just not possible.

3) Feature creep. That old code was designed to solve an old problem, and then modified many times to solve newer problems. There are a ton of features and quirks that aren't useful any more, but nobody removed them. If you tell a PHB "I'm going to remove a feature" they will freak out. If you tell them, "That feature didn't make it into the rewrite because it's not used enough" they will thank you for saving the company money. (Bosses that get it are different, but this tactic is still more palatable.)

1) This is true for YOU not necessarily for the next person, hopefully when you are rewriting the code you maintain some level of decency and leave a comment trail. If you optimize and clean the code there is a high chance that you end up with complex functionality packed into one liners.

2,3) If you do not have a test suite how can you reproduce the original code 1 for 1? Similar for new features. I totally agree that code (at least functionally) should always come with a test suite. If there isn't a test suite and you are planning to rewrite the code, the priority should be in writing a test suite or a black-box tester. At the minimum you should have a list of supported features that you are going to check off.

Ahh, refactoring vs rewriting. All fairly sensible stuff, but while the spirit of the author saying:

"If you can’t implement new features in a clean way I claim: You aren’t really able to implement the whole application in a clean way from scratch either"

is noble, there are surely circumstances where the existing system is so broken/incompatible that this claim might not hold up. However, you would hope competent developers are aware that outright binning a working system is a Bad Thing.

I once worked on a "barely working" application - the original project (which I wasn't involved with) had clearly been a train wreck and it had delivered a tiny proportion of what had originally been promised.

It presented the user with a couple of fairly straightforward screens, did some integration with a couple of other systems but had over 6,000 (not a typo) classes and a dependency on just about every acronym in J2EE. This had apparently taken a dev team of 30 or so over a year.

It was totally replaced by a much smaller application written in a couple of months by a team of three that provided a sound basis for delivering much more functionality than was originally expected.

So sometimes, rarely, chucking away something that barely works is very much the right thing to do.

This article reminds me of "Things You Should Never Do Part I" by Joel, and it certainly echo's the same kind of sentiment towards rewriting your application.

Link to the original article: http://www.joelonsoftware.com/articles/fog0000000069.html

... and more often than I'd care to admit, it is easier and BETTER to quit and find another job rather than "re-write" or "re-factor" somebody's legacy mess. Seriously. Life is too short.

I think the chances are quite good that they were indeed both stupid and evil.

Sometimes you DO have to rewrite your application, particularly if you build it on proprietary software which has support agreements and EOLs which get hit. For example, look at all the crocks of shit hanging around on COM/VB6. They need to be completely replaced.

Reply on news.ycombinator.com