Outsourcing code and how to minimize risks
I want to talk a bit on outsourcing PHP and give some tips on evaluating PHP code.
Many of you already have outsourced coding, or will sometime in the future. I'm a coder myself, but I've outsourced several projects due to a lack of time, and a couple of times I've been disappointed in the end. Either the whole process has been sketchy, the code has been ugly or I've just left with the feeling of being deceived in some way.
Writing PHP is deceptively easy. It's quite simple to hack together some code and see it working. But good code isn't just something that gives you the right results when you give it the right input.
Good code is something that behaves correctly when you give it bad input.
THE "THEORETICAL" PART:
How do I get my hands on this deliciously tempting "good code" then?
1. Ask for a code sample.
Should be obvious for anyone who's bought apples at the market, but in the digital world this is often skipped. Maybe you don't understand PHP at all? Doesn't matter. Ask for a sample.
Do not ask for a sample of the code you wish to order from the provider, but something from past works. Nothing big, just a small sample of some code the provider is proud of.
There's really nothing special that he/she's proud of? Ding, ding say the warning bells...
There's no code that isn't NDA'd or everything's licensed confidentially? This means no hobby projects or other personal interests in coding? Ding, ding, ding...
Asking for a sample accomplishes two things. You actually see a sample of what you are getting, and thus can evaluate it. But it also sets a bar, sends a message that you expect quality code, and will check the files out after the provider sends them to you - probably before the last payment.
2. Never ask for "just something that works"!
I've seen this on Elance and rentacoder time and time again. Someone posts a "quick and dirty job" on the site. Gets a hundred offers, accepts one - sometime in the future receives something that's way too dirty.
You can very well end up with something that works - or you might end up with something that looks like it works.
3. Paying a bit more for good code may actually save you money.
I've had to bill a client a lot more than I should have because of the terrible code I've had to rewrite. Modifying good code may drop my workload by half, and I will show this when I send you the bill.
Any future maintenance operations will be much faster, easier and cheaper if the code is good right from the start.
Also, knowing your code is of good quality relieves some stress. The more unknown factors you have with your websites creates uneasiness, at least in me. Security is something I don't play around with.
4. "This should be very easy."
Yes, some time ago a popular WSO on outsourcing recommended doing this. Right now, it's repeated to death and might not work as you think it does. As a coder, I HATE seeing this on a job title or in the first few lines of the job description.
You'd think it drops the bid prices. It might. But also you are luring in the people who only hunt for the easiest, quickest and dirtiest jobs they can find. You can see where this is going.
There's nothing wrong in saying you think "this should be an easy task". But don't advertise it in the title if you wish to keep the worst providers out.
5. Write as specific documentation as possible on what you want, before closing the deal.
If you don't know what you want, you can be sure your providers will not know what you want, at all. Giving them as much info as possible before they start makes it a lot more probable to get what you want, how you wanted it.
It can also lower the prices providers will ask you. If you tell me "this should be easy", without documentation it might very well be the opposite. If I see a well documented job description and feel the communication is honest, I KNOW if it's an easy job and will bid accordingly.
Also an important point to note: If a work assignment goes somehow bad, and you want out, a good documentation will make solving conflicts much, much easier. When the terms and goals are in black and white, it's much harder to weasel out by referring to "artistic differences".
THE PRACTICAL PART:
Let's get into the code. What to look out for?
1. Bad variable names.
If you outsource to a foreign country with a native language other than English, make sure the code is also written in English. I've had to fix code that had variables written in Hindi. Despite otherwise good documentation in English, modifying the code was slow and painful.
Testing for this is pretty easy. Open the file and start reading. Are the variables (words that start with a dollar sign) actual English words? Most of the variables should be understandable. See a lot of abbreviations or jumbled letters? Not good. $iterator isn't harder to type out than $i or $itr, but makes for much easier maintenance.
2. No inline documentation.
If you think that another person may ever touch the code, have your developers document the code properly. This doesn't just mean the readme.txt with your work, but inline documentation.
Random example (just a quick google result, no affiliates here):
PHP5 PDO Singleton Class
Check out the code example. See the red parts with lots of *'s? These are called DocBlocks - they are a form of inline documentation, and these parts tell the developers on each function what it does, what variables it accepts, what results it should return, and preferably, how you should use it.
Good programmers worth their salt always write inline documentation. There really aren't any good reasons not to have it. If "it's such a small program" and only took 5 minutes to write, it should have taken way less than 5 minutes to write documentation for it.
Here's the most important part: Good documentation is the best sign that the programmer himself knows what he's doing. Clear, organized heads write clear, organized instructions.
3. Bad indentation & filing.
Is the code indented well? In the previous example you can also see some good indentation. Is there enough space in between the code, or does the code look cramped?
Is the provider's submission one huge file, or is it separated into different files/folders? (This might not be relevant for smaller jobs, but keep your eyes open.)
4. SQL and XSS injection holes and bad database interaction.
Now it gets trickier. You have to know a whole lot PHP to see most cryptic security holes, but you can always check for the obvious signs of bad code.
Here are some... Actually, scratch that. I was going to go on a tangent on how to spot bad MySQL-queries and such - but really, there's no point.
Try and search "mysql_" in the program files or the database class file if you have one. You really shouldn't find these anywhere.
There's something called PDO, which stands for PHP Data Objects. It was added to default PHP installations in PHP 5.1, which is now 6 years old. It's a huge help in disabling SQL injection attacks and keeping the code neat.
I'm going to be a bit arrogant here, but: There are no excuses for not using PDO. No amount of sanitization and validation of your variables is ever going to be as good as prepared statements.
If your project is for a CMS, the plugin/theme should use the CMS's own functions and classes for database work. But if the project requires you need to work in your own database, make sure your developer knows how to use PDO!
Quick tip: Listing "Knowledge on PDO and prepared statements required" in your job description helps you weed out the worst providers.
5. Undefined variables and notices.
If you're evaluating a WordPress plugin or something similar, open the main plugin file and right after the first <?php -tag and possible comments, paste this and save:
ini_set('display_errors', true); error_reporting(E_ALL | E_NOTICE);
Be careful with this on production sites! It most likely won't break anything, but if you have badly written plugins your site's frontpage might display a whole list of errors to your visitors while the above line is in your plugin. This is why you should have an empty WordPress installation to test your stuff on first. After checking for notices, remember to remove the pasted lines.
IN CONCLUSION:
Note that these tips don't tell you when code is efficient. Efficient code may well be ugly and difficult to decipher. But good code is also well documented and works when sent bad data.
If you have any questions, I'd be glad to answer them.
This is not a post to turn you off cheap providers, there are a lot of good opportunities out there. Many of these good opportunities are inexpensive. Go out and have fun!
(Five hours later, this really seems longer than what I first decided to write...)
Peace out,
Alfred
"Jamroom is a Profile Centric CMS system suitable as a development framework for building entire communities. Highly modular in concept. Suitable for enterprise level development teams or solo freelancers."