in reply to Re: Perl Code Quality
in thread Perl Code Quality

Maybe it depends on the CPAN modules used, but I was just remarking to someone last week how, with over 300 installed CPAN packages, I can only remember finding one backward compatibility issue in 5 years. We do wrap some, but only if we're extending functionality. Still not a bad idea though.

I would agree that the world is not all OO. We have mostly OO code but there are a fair number of procedural modules. I think the point a lot of people miss is that, regardless of the coding paradigm used, the most important thing is packaging -- things should always be relegated to packages, properly factored out, in a directory structure that allows for additions and changes over time. A friend of mine refers to the base directory layout and packaging scheme one sets up as the pegboard of the programmer's workshop: a place to hang everything and everything in its place.

It seems that a lot of programmers are not very comfortable working by building packages, unit testing those, and building small scripts that use them. For whatever reason, I always find that the average programmer gravitates towards long scripts. I think a lot of people just can't see the pieces as they present themselves. For that reason I'd try to hire at least one senior person who has done a lot of package building. Typically people who have had to build APIs for others to use are a good choice, whether it be in the open source world (like CPAN) or for a company that sells software. The experience of having to define interfaces is not as common as it seems sometimes.