Well, the kind of problem to which I was alluding is that to which mosquito refers to here.

And yes, it is extremely disappointing that so many people set about writing code without a formalized process for doing automated tests. I just finished graduate school and started a new job. On Friday I was introduced to an enormous blob of Perl code, entirely functional, completely undocumented, devoid of unit tests, and with data hard coded into it. I'm trying to figure out how best to suggest that I ought to be allowed to rewrite the thing. Perhaps I ought to suggest first that in order to learn how it works that I write some tests for it, and perhaps write some documentation as I figure out stuff, a Stone Soup strategy if you will. Oh, and did I mention that it's not in version control? The guy who developed it just takes occasional snapshots of the code.

So, basically I'm trying to figure out how to hijack this project and set it right, all without stepping on anyone's toes. I've got my work cut out for me... Or maybe I should just steer clear of it and work on something of my own from scratch. I seem to have a lot of flexibility in that regard, as developers in this group are basically just set free to find interesting problems to tackle. Maybe it'd be better to just lead by example than to try to beat a pre-existing project into good shape. I don't know... Entering a new group is a tricky and delicate process.

I'm starting to feel that it is my lot in life to be a Jonny Appleseed of the software development world.