Advice on hiring a developer - my 10 rules.

Truth be told I haven't written much about my experiences as a forum manager. With time I am slowly opening up to writing more about my day in and day out tasks, duties & observations. With this newly acquired free time I have been reflecting more, taking into consideration more often than before the transactions between myself and the developers I have been dealing with.

So, I have taken the time to put together a quick article of what I believe is important to know as a forum owner when you have no development skills of your own and you are hiring a developer.

Obviously, I speak from experience in this article, it may not apply to you.

I generalize, I am that type of guy.

Feel free to reproduce it but if possible toss a link back to my blog

And so, here we go.... my article is here.

 

Great article! Where do you look for your developers?

 

back to Odesk I have gone.

Previously I was working with 1 dev over the course of a few years but he moved onto bigger projects I imagine. Sad for me, great for him. I have tried to hire via vBulletin.org but too many dodgy coders there.

 

I have/had a great coder, but he also farms so I don't have him 100% of the year, so Odesk I go.

 

Well, wrote a little something up on vBulletin.org

 

Here's some advice I can give you based on my 21 years of professional experience in the software industry:

• If you're working with developers that you don't know, you should make a thorough specification of what exactly it is that you want, as you understand it in your terms. Give the spec to the developer(s) and let them modify it so you know what they think is necessary. Pay them for that work, or ask them if they accept compensation later when the project is complete. Make sure you understand what's written in the spec, and ask them to provide explanations for things you don't understand.
• Once the spec has been agreed upon, work can begin. However, neither you nor the developers can modify the spec afterwards, except if a new spec is made that is then negotiated again between you and the developers. Otherwise, the developers don't know what they're at, and you don't know what you get.
• You do not pay for the project (except the spec) until it is complete. Intermediate compensation should be agreed upon in the spec for partial functionality.
• This is the way corporations like IBM, Siemens, etc. handle successful projects. You can do that too.
• Especially when you're dealing with developers you don't know this can make sure you don't pay more than necessary.
• When you definitely need the software finished at a particular date, make sure there's a project deadline (or several intermediate deadlines) in the specification, and that developers agreed to the spec. If a deadline is overrun, stop the project, if don't have any leeway. Make sure that in project planning, you chose a deadline that is comfortable to you so that you give someone else the task. Do not plan on short notice. I.e. if you don't have enough time to deal with development, don't do it.
• Once a project is running, avoid adding additional developers, since they have to get familiar with the project.
• When a developer makes a time estimate, multiply it by 2 and add another 50%. This will get you a more realistic estimate. Developers often underestimate the work that is needed on a project, or do not take into account problems that might occur during development.
• Some developers might accept a project that is way over their head. Give your specification to them and let them work on a detailed specification for the implementation of the project. Ask the developer if they're comfortable with the arrangement and if they wish to proceed. If you have a detailed specification that everybody adheres to, even less experienced developers might be valuable. But if you notice that a developer will be unlikely to succeed, search for someone else. If your project is large enough for a team, hire several developers of mixed backgrounds, they can often even out each other's weaknesses. If your project is important, hire senior developers for the important parts of the project.

Hope this helps!

 

And as expected. The vBorg thread has been removed......by another developer.

.