The larger a bit of code gets the more bugs there are - end of discussion. Most of the things you mention are ways of expanding the amount of code without increasing the bug count too much. For example CGI::Application is a very small module with almost no functionality that could not be created in a normal script. However it is a standard and well tested start - that is why it gets used. It puts you further along the 'make it work' road with less potential bugs.

I get paid to code. My customers don't pay for lines of code, or code beauty. They pay for it to work, to continue working and then not to break. They are paying for the absense of bugs. The things above - use warnings, use strict etc - help make this possible.

This means that I code simple routines and test them. The code looks and is simple - that way I can run through it in my head and check that it is correct. Then I apply buckets of tests to them.

I think the analogy that fits here is that of a professional football player versus an amateur. The professional footballer is paid to score. They ALWAYS warm up, wear pads, watch their diet. Amateurs play for fun - warm ups are less fun and the pulled muscles will heal in time.

So in summary I'm not sure I agree... I too throw out all the 'best practises' from time to time because they do slow down development. BUT I only do this for small bits of code and they are almost always one offs / one liners - see reply to reply below.

update: changed the first (now last) paragraph to reflect the rest of this post.

update 2: moved the first paragraph to the end - not sure if people were reading beyond it...