Perl Shop Maturity Checklist: Technical Concerns

In the spirit of helping recruiters understand the Perl community better and how to identify a good Perl programmer, perhaps it's useful to discuss ways to identify a good Perl programming shop.

I see three aspects of maturity in any programming job: technical, cultural, and specific to the programming ecosystem.

These aren't rigorous guidelines. I'm not writing a purity test, and you don't have to answer all of these the same way I do to get a perfect score. (Why would you want a perfect score from me anyway? I run my own business and, while I'm available for contracting and consulting, I'm not currently looking for full-time work.)

Disclaimer aside, if you find yourself disagreeing with these questions (or if you've never considered them), your workplace may not be inviting to good programmers. Process for its own sake isn't interesting, but the ability to define what should happen when and who does what and how to resolve conflicts is vital to having a healthy business.

Let's start with the technical questions.

• Do you use source control?
• Do you stage deployments?
• Do you have a defined process for deployment?
• Do you have a defined process for rolling back a failed deployment?
• Do you have code that "no one knows what it does"?
• Do you have critical business code written more than five years ago that people are afraid to touch?
• Do you have coding standards?
• Does most of your code follow it?
• Can you tell who wrote each piece of code by its style?
• Do you have a standard technology stack?
• Across multiple applications?
• If some applications don't meet it, do you have plans to refactor them?
• Do you refactor at all?
• Do you have a defined process for handling bugs?
• ... for handling feature requests?
• ... for scheduling delivery?
• Do you have a training or mentoring process?
• Do you have multiple developers?
• Can you retain developers for longer than one year? Five years?
• Do you use automated tests?
• Do your tests all pass?
• ... before you check in?
• ... before you deploy?
• Do you have backups?
• ... for servers?
• ... for developer workstations?
• ... and do you test them regularly?
• Are developers their own system administrators?

In short, how predictable is your development process? Can you manage risk? Do you? When surprises happen, how much work is it to recover? The better your answers to these questions, the more likely that you can attract and retain talented developers—and make the most out of their abilities.

What other questions would you put in this list? Why?

If you'd like a detailed discussion of how to apply this list to your own company, I'm available for consulting.

(Next time: cultural questions.)