10 Things To Know BEFORE Hiring A Freelance Programmer

Robert Plank 10 Things To Know BEFORE Hiring A Freelance Programmer
by Robert Plank

To avoid the same mistakes I see marketers making over and over again, there are a few things you need to know before you hire that eLance, Scriptlance, or RentACoder software developer.

Law 1: Your software needs to be created in small steps.

It's more expensive that way, but at least you can get your version 1.0 out with the basic features. Once you have that base just pay the programmer on a case-by-case basis depending on which SMALL feature you want to add.

Get your version 1.0 working, fully error-free, tested, and SELLING with the site live before adding features for version 1.1, 1.2, 2.0, etc. When you move on to these newer versions make sure it is all error free and selling on your site before continuing.

After the initial version has been written you will know exactly what you're paying for.

Keeping it simple allows you to be very specific about what you want your script to do without overloading the programmer with details.

Small steps also mean any changes to your software project will happen fairly quickly. If they don't, you can ditch an unreliable programmer without losing months of time.

Law 2: Programming will cost you money.

Every once in a while some guy I used to do programming for but haven't had time for in a while tells me about a programmer in India, or Russia or some other place who spent a day writing a script and it all cost him a grand total of... 6 dollars.

Then I take a look at the script and it looks like about $6 worth of work to me.

There is no reason to go ultra-cheap on the money you put into creating your software product. Your only expense is the cost of having it developed, everything after that is pure profit.

A (print) book publisher will pay an ex-President millions of dollars for a ghostwriter to produce an autobiography, because once the actual text is written, the publishing company can start manufacturing books for a dollar or two and sell it at $29.95. It's the same idea here, most of the expenses will come now instead of later.

Law 3: Most programmers know "diddly" about marketing.

Sorry. It's just a fact. Most of these guys have been creating the exact same script over and over... usually bad ones like a traffic exchange or dating script. Be patient and explain split-testing, double opt-in or whatever needs to be explained and if the programmer can't understand those concepts just go with someone else.

Law 4: The code needs to be well documented (comments in the code), that way you can come back to it.

If you find a problem with your program a year from now, even the original programmer will be clueless UNLESS there are comments within the source code explaining very clearly what every function and block of code is supposed to do.

Law 5: Your programmers need to speak decent English.

Not that Indian dialect of English either, real English. This is definitely not the time to lose anything in translation. Plus if everything's in another language how can you possibly switch to another programmer if you need to later?

Law 6: You will almost always catch stuff the programmer didn't.

There is a real thing called Programmer's Immunity. Basically it says that the "average" user will have more computer problems than a programmer, because a programmer is used to making things work (work-arounds). This means every once in a while, your programmer will subconsciously miss bugs that are glaringly obvious to you.

Don't get annoyed, just let the programmer know about the problem, and what exact steps need to be performed to reproduce the error.

You will need to test the program yourself. You will also need to send the program out to beta testers to make sure others can use the software without problems AND you need to find out if the program can be used without instructions by someone who has never seen the software before.

The installation instructions need to be worded as simply as possible, without a lot of legalese or technical terms.

Law 7: (For web-based apps) use HTML templates.

Most programmers I've seen are shitty designers. This way you can change the way the script appears and even hire out a professional designer.

You need the programmer to use a very simple template system.

In PHP this would be something like FastTemplate, where there is a simple "tag" in the HTML like {firstName} or %firstName%. There are other bad template scripts for PHP such as Smarty, which sucks because it embeds PHP code in the templates. You'd have the same problem using regular PHP. The whole point of having templates are to separate the code from the appearance.

Law 8: If you can afford it, get a code inspector.

This is a programmer you know to be good but maybe too expensive to write the entire script, who can take a quick look at the code after every release to make sure the program is "good enough" ... not perfect but sellable.

Your inspector is only looking for HUGE problems in the program or script like the usage of gotos or globals, or maybe your freelancer is using a database but hasn't normalized it properly or forgot to add indeces where they are needed to keep the database fast.

Law 9: Stay away from GPL, open source, and re-used code AT ALL COSTS!

This is a biggie. Make it clear you do not want code reused from other scripts. Obviously if the coder uses parts of someone else's script you are in violation of copyright laws.

On the other hand there is free software out there called GPL (GNU Public License) which is free to use but only if you make the source code of your entire software product available as well. That is definitely NOT what you want.

Law 10: Your software will break over time.

This is just a fact. If you're having some desktop software created in C++ the code might not compile correctly on a different compiler in a few years. Some software written in version 1.0 of Microsoft's .NET runtime already breaks when you run it on computers with version 1.1 (argh!)

Don't even get me started about PHP. When PHP releases new versions the new ways of doing things are not always backwards compatible. Depending on which modules or security patches a given web host has installed, certain functions may not work as well. You just have to test, that's life.

About the Author

Check out Robert Plank's e-book, Sales Page Tactics
http://www.salespagetactics.com/Your_Clickbank_ID
... For a ton of PHP advice and easy fixes to your marketing problems.

Publish me!! This article may be freely distributed as long as the whole thing (including this notice) remain intact.