Really? Where's your first major module? Does it have a comprehensive test suite that registers at least a 90% using Devel::Cover? Heck, I have a CPAN distribution that is close to 10,000 lines that barely breaks 60% coverage and a multi-billion dollar company uses it as a major underpinnign for a $100Million/year application.

Remember - the first rule of code is "It has to work". Nothing more, nothing less. Anything beyond that is gravy. Code will not suddenly develop bugs, just by sitting there and being used. Software develops bugs only by developers introducing them.

Being right, does not endow the right to be rude; politeness costs nothing.Being unknowing, is not the same as being stupid.Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Yes, code can "suddenly" develop bugs, if something external changes, such as the environment or input data (remember Y2K?). Just because "it's been working for years" doesn't mean it can't break in the future, even without a code change.

Many of those applications that were hit by Y2K were developed 20+ years earlier and were supposed to live for 5-10 years. They were way out of spec.

It's arguable that 2-digit years were a premature optimization, hence a bug.

The point behind me statement is that many younger developers feel that code "rots" - that it will break in spontaneous ways if they don't get to rewrite it. If it worked yesterday and, all things being equal, no-one touched the code/environment, it will most likely work today.

Being right, does not endow the right to be rude; politeness costs nothing.Being unknowing, is not the same as being stupid.Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

10,000 lines is crap, and you'll never convince me otherwise. So lets just leave it at that.

And whats with the "wheres your first major module" shit ? I've written dozens of modules for my employers, most of which have 100% coverage in D::C. Furthermore I have contributed several patches for Class:DBI as part of the Phalanx effort, all derived from using D::C. I dont have to contribute to CPAN to have an opinion, cockhead.

...it is better to be approximately right than precisely wrong. - Warren Buffet

Then the first part of refactoring is to bitchslap the original developer....

I dont have to contribute to CPAN to have an opinion, cockhead.

No, you don't. I used the example of my module on CPAN so as to:

Demonstrate the issue isn't just with legacy code (I still actively maintain PDF::Template)

Demonstrate the issue using my own personal code, saying everyone suffers from a lack of knowledge (the code was written over 2 years ago) and tuits (I have been focusing on other work and haven't written the 500+ tests needed)

How do you 'know' it works ? It isnt tested.

Wrong - it's "tested" over 25,000 times a day. In other words, I 'know' it works because that's what it does - work. I know the 60% that's covered works, too. I am not comfortable with that, so I will be adding more and better tests to the regression suite.

Being right, does not endow the right to be rude; politeness costs nothing.Being unknowing, is not the same as being stupid.Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.