I wouldn’t hesitate and rewrite the stuff

Though it might feel more enjoyable, do you have a sound reason to believe you'll do a better job than the original author/s? Are you smarter? Do you have more time? Do you understand the business better? Have the business constraints changed?

Some cautionary advice on the perils of rewriting from scratch:

Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long time in the Internet world. During this time, Netscape sat by, helplessly, as their market share plummeted. It's a bit smarmy of me to criticize them for waiting so long between releases. They didn't do it on purpose, now, did they? Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

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.

-- Joel Spolsky on not Rewriting

Now the two teams are in a race. The tiger team must build a new system that does everything that the old system does. Not only that, they have to keep up with the changes that are continuously being made to the old system. Management will not replace the old system until the new system can do everything that the old system does. This race can go on for a very long time. I've seen it take 10 years. And by the time it's done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it's such a mess.

-- Robert C Martin in Clean Code (p.5)

More detail on this topic can be found at: Nobody Expects the Agile Imposition (Part VI): Architecture

«...a sound reason...»

Sure. Consider this true story: Once upon a time a young C programmer needed a little script. In his hubris - a real Dr Wisenheimer - he wrote it in an obsolete Perl 4 style. Everything self made. No libs etc. Some years later a bash programmer (a real Perl hater) inherited the script. At this point the little script was already swollen to a monster of many hundred lines of code. The basher left the company and a real Java fan boy inherited it. He added tons of features and libs. Now this whole crap is by far > 1000 lines and really stinks. It is mission-critical. If it fails: Airplanes grounded, 100 printers down, VPNs broken, monitoring runs amok, what ever desaster you can imagine. And a poor 24/7 admin needed to restart the stuff every time it crashed. Sure, this is prose. A short summary of my experience. The statement is: Sometimes it’s better to make a hard break. Who will be killed if such crap fails? The poor guy which inherited it. And: If you want to maintain or extend such stuff you need to understand it’s logic. BTW, my second project ever was a complete rewrite of the crap I wrote in my first project. After I «discovered» how it really should be done.

Best regards, Karl

«The Crux of the Biscuit is the Apostrophe»

perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

Let me get this straight. It started with a small Perl 4 style script, written in Perl 5 by a hubristic C programmer? Did the basher rewrite it in bash? Or just add some bash to the existing Perl 4-style Perl 5 script? Did the Java fan boy rewrite the whole thing in Java, or just add some Java to the existing Perl 4-style Perl 5/bash hybrid? ... I agree that a "Perl4-style Perl 5-bash-Java hybrid" written by a C programmer is probably ripe for a complete rewrite. :)

my second project ever was a complete rewrite of the crap I wrote in my first project. After I discovered how it really should be done

Sure, this can work well ... like the Perl 5 rewrite of Perl 4 ... or not so well, like the Perl 6 rewrite of Perl 5. :) Beware the Second-system effect.

To rewrite the stuff is an advice which is often given in third person. Seriously, if the OP has doubts about the business logic, then rewriting is a bad advice, regardless of how funky an object model (or modulinos) might be.

Rewriting is fine if you can afford to do it for fun, or if you have a sponsor/employer who pays you for exactly that job. Otherwise: just don't do it.

This would be nice, but is often not possible when dealing with tons legacy code or thousands (or millions) of LoC. There are many reasons for this: time, risk, money - but most importantly, business logic - much of which is baked into legacy code. Besides, once you move to modulinos (my suggestion) then progress to full modules, it's then much more convenient to refactor in a more modern way as you suggest. Consider the number of man-hours put into the "working" code - it will take even more time to replace the code due to the requirement to necessarily understand the code (even if you wrote it) and replicate all the assumptions both inside of the code and by anything using the code as a black box. It's super hard. Personally, I aways recommend against rewriting or fully replacing code, especially replacing Perl with another, inferior language xD.