If you've ever started to wonder how good your Drupal development company is, here's some questions that will (hopefully) reassure you—or at least educate you. Or if you're looking for a development company, these are great questions to ask to help determine the level of the expertise. If you decide to compromise for price, you'll at least know what you're getting into.
So we're on the same page...
These are general development practices, not Drupal specific; though I am looking at them in terms of Drupal specifically. This won't help you gauge their skill with Drupal itself, merely how well they adhere to standard Drupal development practices. While I will say that it's a good bet that a development shop that follows best practices is an above average firm; I should also note that following good standards does not necessarily indicate superior skill.
I haven't seen any developers who follow best practices and are simply terrible, but I have seen my fair share of developers who follow best practices but just can't get the job done for whatever reason. Some other time I may write some questions to help to interview a Drupal developer on their Drupal skill specifically.
Questions to ask:
- Do you use version control? Version control is a tool for tracking changes to code. It can also serve as great backup tool. Possible answers:
- Yes, we use Git. This is the best answer. Best because Drupal uses Git for it's own management, so they're more likely in tune with Drupal best practices.
- Yes, we use a SVN/CVS/Mercurial/etc. This is acceptable. I won't go into the different options here, but anything is a good sign.
- No. This is a bad sign. This means they're far from an enterprise company. It means thing aren't being done to what has become an industry standard. It means there is greater chance for things to go wrong, and a tougher recovery if they do.
- Do you keep regular backups? This is just a way to tell how serious they are about the safety of your data. If they're not hosting your system, this is actually not their responsibility. Despite that fact, they should be keeping backups of everything they touch.
- Yes, we have automated backups running for your database (most important), code, files and server at least once a day (hourly is better). This is the answer you want. Less than once a day (unless nothing is happening on the system during that day) means the impact of a crash or a mistake could cost you days of work and data. Any longer than this shows an amount of negligence. Keep in mind that depending on your relationship with them, they may not be capable of performing all of these backups.
- No. or We backup manually every so often. This is more common than you'd think. Mistakes happen, systems fail: and it often happens when you're least expecting it. This demonstrates a lack of experience or plain negligence.
- How do you transfer files to the system? This might seem minor, but how a company moves files around says a lot about their workflow and astuteness.
- We use SSH/shell access. This is ideal. This is the most secure way to interact with a system. This means they're comfortable using command line. If they use a version control system and they're not using this... they're not using a version control system for the deploy.
- We use a deployment tool to stage and deploy sites. This is better than the above option. This is more enterprise, so it's a really good sign. It's also more expensive in general; to do this correctly you can expect to pay $200-$400 a month in hosting alone. (Having said that, we use some of these tools, and we consider it development overhead—so we don't pass this cost along to our clients.)
- We use FTP. This is a bad sign. There's nothing inherently wrong with FTP, but to use it for a deployment workflow leaves a lot of room for error. Given the risks involved, any developer using it is either inexperienced or not familiar with SSH. There's also pretty serious security implications of using FTP; though these are mitigated by using SFTP.
- How do you access the database? This is perhaps the smallest issue here for a simple reason: most good Drupal developers shouldn't actually touch the database on a site. Drupal is so powerful that you can build a very powerful system without ever touching the database. Nonetheless, the database tool of choice will help you gauge their technical astuteness in general. Also, a lack of technical astuteness in this area in particular begs the question: "What happens if there's a problem with my database-driven site then?"
- We use SSH/command line to access the database. This is best, as with the previous question; this demonstrates a comfort with a more powerful tool. This basically rules out the possibility that your developers are database novices. Even if your developers don't prefer this as tool, you might ask them how familiar they are with it; familiarity with it is a great sign.
- We use a desktop based client that connects through SSH. This is also good. A good tool here typically packs similar power (sometimes more) to what you can expect from a command line tool. However, unlike the SSH option above, this doesn't completely rule out the possibility of novice developers; that they connect through SSH probably means they're concerned with security, which is a good sign.
- We use a desktop based client that connects directly to the MySQL server. This is ok. It's not quite as good as the above option, especially from a security and flexibility standpoint. Connecting directly to the MySQL server probably means they're not aware of the security implications of that at the server level, which could be a red flag. However, it can be just as powerful.
- We use phpMyAdmin (web based). This is not ideal. A lot of developers use this as their primary tool. See my note on the question itself: this doesn't have to be a deal breaker, merely a flag. This generally means they're not as familiar with MySQL databases; they haven't done enough to get irritated with this rather limited tool. It's great for a web based tool, but this isn't a tool enterprise developers prefer.