When you said "development environment," I was wondering if you meant software environment or human environment. From the text following, I guess you meant software environment.

Before you can tell what software environment best for you, you should figure out first what human environment, what development process, style, etc. you want for your "next step."

One of the best features of Perl for personal use is its flexibility. One of the main problems of Perl for team environment is also flexibility.

If you're planning to add more people, one thing you should figure out is what programming style, naming convention you want. It may seem inconsequential. But when you have a bunch of people writng code in completely different ways. That makes maintenance very hard.

One way to enforce style and convention is to put "templates" in source control. And everyone starts writing their codes from a template. (CVS and MS SourceSafe are both good stuff, but have opposite models. CVS has a client-view model; SourceSafe server-view. It's just a matter of preference which one more convenient to you. CVS is free, however.)

Deployment process is another important thing, especially if you build websites. Again, source control will be an important piece of tool there.

I found most programmers prefer simple editors to fancy and very very expensive integrated tools, such as those from Rational Rose (people who bought them or recommended them were often the people who didn't code).

Get yourself a graphing tool, such as Visio, if you prefer visualize your architecture graphically. At least, I found a graphical database schema extremely effective when used to communicate architecture among programmers.

You should define at each developmental stage, what "artifacts" should be produced. Like, during requirement analysis stage, artifacts could be Use Cases or requirements that have clear indications of "input-output." During design stage, they could be class diagrams, activity diagrams, database schemas. Etc, etc.

A purpose of those artifacts are to serve as some quality control checklist, so that least miscommunication may occur and minimal essential requirements may fall through the crack.

Whether your environment is "object-oriented" is not important at all; it's merely a marketing hype. To me, the best team environment is the disciplined one, yet still fosters creativity. But it would take a long essay or a book to describe how to do it.

___________________
Update: Oh, I found some teams liked to use Gannt chart (drawn by MS Project or whatever). But pretty much everyone likes white board. Small portable one, as well as the huge wall-to-wall one. And plenty of color markers.