perl shop (im)maturity

When I was working on my talk about the Perl API at NetCon^[1], my manager asked me to come up with some Perl questions to figure out the Perl literacy of the audience. Of course asking about the audience's literacy during the talk was far far too late, but not having access to them before hand was not my choice. I hate Perl interview questions because they usually test for syntax or features that are easy to look up in the manual, and not necessarily what you use day to day as a Perl programmers. They tend to obsess about regular expressions, which are an important part of the Perl language, but reliance on regular expressions when there are better tools is an important pitfall to avoid^[2]. If I were hiring someone I would ask them about the projects they worked on in the resume and how and why they made decisions in a Perl context on those projects. Of course you can't really do that in a short survey so I came up with the interview questions, which I hated.

Chromatic just posted Perl Shop Maturity Checklist: Technical Concerns about questions to ask a potential employer (the shoe is on the other foot, as they say). If I had asked these questions of NetCon, here is how they would have answered:

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

On paper it doesn't look that terrible, not everywhere has everything right or the way you think it ought to be. Besides, I was desperate to get out of my position at The Bureau, so I might have taken the NetCon job even if I had known the answers to these questions. Some of their questions in the interview were definitely warning signs of bad things to come, but I ignored them.

---

1. Can I just say how glorious it is that I am talking about working at NetCon in the past tense now?
2. Parsing XML with regex, for example is stupid, don't do it