"Drupal is 'free', open-source, popular, with a large community and tons of modules.
So it must be a good idea to hire a Drupal developer to develop our backend",
thinks the staffing manager / development manager / project manager / team managers / CTO / ___ manager.
"Why hire an external company to do our next enterprise system when we can develop it in-house?"
Here are the top mistakes done when staffing Drupal projects:
- Not distinguishing between Drupal integrators, web developers (module programmers), designers, QA people, UX people, content people, team leaders and project managers. All of them are needed for a good project. And if you can't get them in-house, consider outsourcing some of the functions to freelancers or outsource all development to a Drupal development company. It's rare for a single freelancer to posses all qualities - we are all human.
- Thinking Drupal == PHP. Reasoning like :IF a web developer is good at PHP (and GIT, HTML5, CSS3, and jQuery) THEN he will be able to create a great Drupal website in NOTIME.
- The Portfolio Syndrome. Thinking that developerQuality == NumberOfWebsitesInProfile
- The Years syndrome. Thinking : developer's quality == # of years in Drupal development. Actually, more is not always better. Is the experience current?
- The Code syndrome. Thinking: developer's experience == # of modules s/he contributed back to the Drupal community. Problem is that there is lots of great code which is propriertary, and that there are many good Drupal integrators who are not developers.
- Thinking Drupal == Free. "We ain't need no developer! We can do everything ourself - let's give it to one of our in-house staff person as a project". This line of reasoning resulting in a project which looks like a first project. Or a project which looks like a PHP project.
- Not doing your research before starting staffing. There are many good Drupal companies. Not doing your research will probably result in selecting a company which will reinvent the wheel.
- The man-months myth. Asking a developer how much time will it take and using this time for a price estimate.
What should you actually consider: For a basic drupal integrator job, I suggest starting from the following questions:
- Which versions of Drupal you used?
- What are the top Drupal modules? Not using top modules is a common beginner's mistake. I've seen a first Drupal project where everything was coded in PHP + Javascript. Not using views, not using CCK. Just using Drupal to store the data.
- Which modules did you actually use? Which modules do you love? Hate?
- What are the top base themes you recommend for Drupal development nowdays?
- What do you do before starting the actual coding (should do a research to find if such a solution exist, or ask friends).
If the person is intended for backend module development, and you are looking for a real drupal expert doing module development himself, check for the following criterias:
- Number of people who are actually using the modules contributed by the developers (sum the drupal.org stats).
- Number of points the person is having on the drupal.Stackexchange.com tech support community.
- Involvement in the Drupal.org support community. Number of comments and their quality.
- Number of articles s/he has written about Drupal and their popularity. # of comments about each article.
- Quality of the module's documentation.
Photo credit: office.microsoft.com design gallery.