For a while, I've felt that writing good software must involve at least three people: a coder, a user interface designer, and a tester. However, most of the Perl projects I've worked on professionally have been lone-wolf projects. A manager has said, "Stephen, here's a hammer and some nails; build an ocean liner," and I was off on my own. After doing this for a bit, I've come up with a method of getting some of the benefits of working with a team without adding anyone else to the project.

One of the main reasons that there must be multiple folks on a project team is that it's possible to know too much about the whole project. For example:

• If a user-interface designer knows too much about the deep internals of a project, she won't approach the code the same way that an uninitiated user might.
• If a tester knows where the questionable spots are in the code, and that the more bugs she finds, the harder she'll have to work to fix them, she may unconsciously neglect testing those areas.
• If a coder does user-interface design, the UI may get tied into the code very closely, and modifying the code in the future might become more difficult.

However, in a pinch, I've learned to avoid some of these problems with a bit of self-induced multiple personality disorder. (Multiple-personality disorder seems to be real, and I don't mean to trivialize it by bringing it up here.) With a bit of method acting, one can keep the designer's persona separate from the coder's. The techniques are simple and subtle, and probably many people use them without thinking about it. Drumroll please... the techniques are:

Consciously switch roles. When you've been coding for a while, and are switching to testing, take a second to remind yourself that whereas before bugs were bad things that you didn't want to see, now they're good things that you WANT to see. Think of yourself-the-coder as "that lunatic whose code I need to check." Don't let yourself change user-interface requirements because it's a little harder to code that way; think of how yourself-as-interface-designer would yell at you if you did.

Keep phases distinct. Work in different subdirectories depending on your role. Use different tools. Put HTML in templates and use an HTML editor to edit them. Automate your unit tests so that yourself-as-tester can work alongside yourself-as-coder easily. Using different tools and environments for different jobs makes it easier to remember who you're supposed to be right now.

Finally, it's sometimes useful to think of yourself as the manager of this little hallucinatory workgroup. Being the imaginary manager can give you some much-needed perspective on what you're doing, and can make it easier to give accurate answers to requests for time estimates.

(Just don't be your own pointy-haired boss...)

stephen