A Survival Guide for Outsourcing

Postuar në - Ndryshuar më së Fundmi më

Software engineering

The hardest part of building a start-up for me was dealing with programmers. Don’t get me wrong, programmers are clever and talented people, but they are so busy focusing on micro problems, they often can’t see the "forest through the trees".Waiting on programmers was definitely the main factor that slowed the whole process down the most and caused the greatest stress for me. I’m not a "qualified" programmer myself. Everything I know in regards to coding is self-taught., I used to build websites and I built & designed a majority of the Whizbang website myself, Despite this knowledge, the technical development of the site was the biggest learning curve from which I learned a lot of lessons (particularly in regards to programmers).. So let me save you some pain and effort and share with you my hard earned wisdom.

Lesson 1: There are “programmers” and there are “programmers”

Not all programmers are alike! A “programmer” can be someone who taught themselves to use templates to put content together to create simple websites. If this is all you need, then they will do just fine (just don’t pay them too much or expect any type of customization). On the other hand, there are also specialist programmers who have years of experience & can build complex site components such as databases, PHP forms, interactive features (e.g. reviews, payment systems, calculators, etc.)  and dynamic content.  I learned that if I wanted the job done quickly, properly and cheaply, then I got a programmer who specialized in what I wanted. "Generalists" can tend to” learn on the job” (unless you want something simple) which is often at your expense.I also learned that there are a lot of “cowboys” in the industry (shoddy amateur programmers). They are sometimes self-taught (yes, like me) and use a lot of hacks or shortcuts to get the job done quickly. Even if they do succeed, you will have no idea of the mess that lies under the surface. They may have used an excessive number of styles or cut corners by copying and pasting code from other sites causing unnecessary bloat which will slow your site down. Their coding may be impossible to build onto later (especially by other programmers). There may be bugs you don’t know about until further along the track or worst of all, the whole site might collapse when traffic increases. They may have even exposed you & your users to security threats by not using correct protocol when building the site.It took me 5 months and a lot of money to repair the damage from a bunch of incompetent programmers. In hind-sight we should have rolled back the site to before they touched it and started again, but I had no idea of the degree of damage & I just kept forking out good money after bad fixing it until it was too late to turn back. It took me five days of intricate work just to clean up all the duplicated and unused css which made the site impossible to do further work on. I suppose the only way to have avoided this was to pay another specialist programmer to test their work as it progressed

Lesson 2: Never pay a programmer hourly until they have earned your trust.

This is one of the first and most painful lessons I learned early. Paying a programmer hourly is like giving them a blank cheque. You have no idea what it’s going to cost you and they can basically do whatever they want. I had several programmers that I paid hourly. In most cases I got massive bills and in one case absolutely nothing in return. A programmer has no incentive to work efficiently or quickly if you’re paying him hourly. In fact, the more mistakes they make and the slower they go, the more they get paid. I was paying hourly wages to a local programmer as an employee which was even worse than just contracting because legally I could not ask for the wages back. I could only dismiss him and he didn’t care in the least because he could just go find another sucker. I had no way of knowing what he was producing because (as is often the case  in programming), there is nothing to show until the very end (well at least nothing you’d understand). After three weeks, he delivered basically nothing useable and I had to pay him for his hours (which were probably imagined). Paying a fixed price for a project is the smartest system if you don’t know your programmer well. Admittedly, it’s difficult for anyone to estimate what a programming task involves but a fixed price does shift responsibility onto the programmer (who should know what they are doing).

Lesson 3: Pay most of the cost at the completion of the job

It’s also important to retain most of the payment until the completion of the job. It is very common for incompetent programmers to not finish a job because they usually can’t. A half-finished piece of code is generally worthless to anyone, so even if you paid half the cost…you’ll have to start all over again having accomplished nothing. This is particularly important if you are building an IOS App. There is a good chance that the app will get rejected by Apple if it has any bugs or problems. If the programmer knows that full payment won’t happen until after the app is accepted than you can be reassured that they will do their utmost to build it properly.

Lesson 4: Set smaller tasks

After a while I realized that it was much more efficient to allocate smaller tasks rather than larger projects. This had many advantages such as:

(a) being able to discontinue working with a difficult programmer without losing too much time or money

(b) allocating tasks to other programmers if a programmer was working too slowly

(c) providing opportunity to test out a programmer on a less riskier scale before trusting a bigger task to them.

Lesson 5: Provide precise specifications and detail 

Having been a teacher, I was good at providing specific instructions for my programmers and they all appreciated it. I never assumed that a programmer would just understand what I wanted, but rather I would always go out of my way to provide detailed images of exactly what I meant. 
I always try to keep it simple and as visual as possible using lots of arrows, explanations and even a check-off list so everyone knows what is and is'’t completed. I also discovered that if I wrote too much text, they would NOT read it. So I had to also keep it brief.

Ensure that you regularly ask for the source code, any keys, passwords or access information, particularly if it’s an App. You’ll need to upgrade it regularly and you don’t know if that programmer will always be around or willing to work on it for you again.It’s a good idea to have this delivered to you at regular intervals in case the programmer disappears. There are online sharing programs which programmers can use to code into making it accessible to others. E.g.  Github, Bitbucket etc

Lsson 6: Getting Quotes 

Knowing how much a programming task will cost is like asking how long a piece of string is. Quotes can vary tremendously. I’ve had quotes that range from $500 to $ 5000 for the same task. One company tried to quote me 3 days to build a button. When we received some funding, the companies we approached just happened to give us a quote that matched the funding amount (yes, they knew the amount). So, you will generally get quoted according to what they think you will be willing to pay and not for the actual work.You can also influence the quote favourably by providing very specific specifications. You will be more likely to get an accurate and realistic quote if you provide detailed information. People are more willing to drop the price if they know that there won’t be any nasty surprises or unforeseen work. In other words, if your specs are vague, then they will generally quote higher. to cover themselves.

Lesson 7: Using Third Party Outsourcing Sites

I have to say that in the end, after trying different approaches (local contracting, wages, development companies), I finally decided to go with third party outsourcing sites such as Freelancer and Upwork, Why? Because they gave me protection. These sites also give the freelancers the incentive to protect their long-term reputations, thereby providing their best effort. There were a few areas where I did get caught in the beginning. Here are some of the mistakes I made: 

On several occasions, I gave freelancers good reviews before I discovered that they had done shoddy work causing other issues down the track. It’s important to test the work thoroughly before releasing funds. In fact testing is a major job and you will need to allocate a fair amount of time to doing this.

I allowed freelancer’s to talk me into paying hourly (yes we' talked about this earlier).They explained convincingly that they needed to get their hourly record up and reassured me that they would only charge a capped amount, but I soon learned NOT TO  pay hourly unless I totally trusted them.. One freelancer charged me 30 hours to do a 2 hour job. There was little I could do about it.

Check out your prospects very carefully. Once you accept a freelancer, you are basically stuck with them. Be strict about the completion date as it’s not uncommon for them to take their time, particularly if they are working on multiple jobs at once. Don’t always believe what they say on their profiles. I soon learned to check out profiles very carefully. Some would use templates as portfolio samples. Some would make websites for friends & family to bolster up their histories. Read the references very carefully & read between the lines. A freelancer with references that are blank is not a good prospect. Most people are reluctant to give negative feedback. No feedback can signify a dissatisfied client not willing to complain. Don't be seduced by cheap hourly rates because they mean absolutely nothing. An inexperienced programmer with a low hourly rate can be far more expensive than an expert programmer with a high hourly rate.

Do not choose programmers who respond instantly to a project. They most likely haven’t read the specifications and have no idea if they are capable of delivering. They will just waste yor time.

Give honest feedback. Don’t be coerced into providing positive or no feedback when the freelancer didn’t deserve it just because they begged you or offered you a discount/refund. The system only works when people are honest. Everyone should be allowed the chance to know the truth about each and every programmer.

Conclusion:

These are just a few glimpses into the do's and don'ts of hiring programmers. I could easily write an entire  book on the topic, but I have an entire start-up to run. Building a start-up takes guts, determination and the help of good programmers you can depend on. It may take time to find those programmers and learn how to work with them, but it’s crucial to the success of any project.

Note: If anyone is in need of excellent programmers, let me know what your requirements are (e.g. IOS app, general website, database etc) and I would be happy to pass on the contact details of some of my best independent freelancers. It took me years to find these people so take advantage of my recommendations.

Artikulli tjetёr

What Freelancers Can Learn From the World's Most Influential Women