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.