By Bob Brodie, SUMO Heavy Industries
There are thousands of Web development shops with different qualifications, certifications, partnerships and rates. These factors should be considerations when choosing a developer, but there's more to know when looking to get into a long-term relationship. It's like the difference between asking a girl to the prom and putting a ring on her finger - you'll want to be sure about what you're getting into.
Like any good professional, developers learn along the way, discovering which tools work best, what clients' expectations are, and how to meet and exceed them.
To ensure a positive experience for all those involved, consider asking these five
Whether you work with a freelance developer or an agency, code versioning should be a topic of discussion. If a developer is still manually copying files to and from a server, you don't want to work with them. By not using a code versioning system, such as Git, many vital aspects of a project are lost including change history, workflow, rolling back code and accountability.
Knowing how potential developers organize their day-to-day work, as well as who did what and when, provides accountability and peace of mind. If you can't see how much time went into a specific feature or issue along with what was changed, something is wrong. There is an abundance of systems that make this data easy to track and retrieve. When it comes to ticketing for example, my company uses most of the Atlassian suite. The process goes like this: tickets go into JIRA/Greenhopper, times are estimated and developers add work logs. Additionally, FishEye integrates with JIRA, analyzes every commit message and ensures source code changes are attached to a ticket.
Whether it's a content management system, an ecommerce platform or even a development framework, every established system has best practices and development standards. Potential developers should adhere to these principles, which apply to documentation as well. Essentially, you want to know if developers are following standards when documenting. In our own experience, these standards took some time to sort out. In the beginning, things were not as firmly entrenched as they are now. My company follows Zend Framework coding standards and PHPDocumentor standard, but we also stay current with best practices of every system we work with. If any code slips through that doesn't conform to a standard, it's rejected and fixed.
This seems obvious, but should be asked in the context of, "Is this developer qualified to work on my project?" Not every developer is certified. Not every developer can afford to be nor does every developer want to be. A good developer will never (ever) be offended if you ask for a code sample. In fact, any good developer should be proud of their accomplishments. If you're not familiar with the more technical aspects of the work, ask for some documentation on the system or framework they'll use and how it applies to their sample.
When you own a business, every second of your time is worth something - to you, to your employees and to your customers. Time is not something to be wasted or to take for granted. Make sure there's a system in place to know how developer's time on a project is allocated and that you're getting what you're paying for. Reports are essential, even simple ones.
When you engage a developer on retainer, reports are even more vital. From the developer side, a project is about creating a timeline and sticking to it. However, under a retainer model, developers must constantly prove they are not wasting time and money. Just because they do what the client wants doesn't mean they're awesome, just convincing.
I recently discovered a plugin for JIRA called Tempo, which produces worksheets for every team member. The worksheets are automatically generated every time a ticket is updated. This allows me to easily provide weekly statements for our retainer clients.
Consider these experience-driven points when choosing a developer. Don't ever be afraid to ask questions and don't ever go with a developer simply because of the rate. Know that the cheapest isn't always the worst, and the most expensive isn't always the best. Asking questions is the only way to choose the best team for your project.
About the Author: Bob Brodie is a partner in SUMO Heavy Industries and Head of Technology Experience. Contact him at robert@sumoheavy.com.