How To Hire Programmers and Outsource Software Development: Commentary, Tips, and Best PracticesOffshore Software SuccessLearn to outsource with freelance software developers.Interesting Comments on the Seven Mistakes when Hiring a ProgrammerHere is an interesting message I got from a freelance programmer in India. Seems my articles on the Seven Mistakes people make when hiring a programmer struck a chord with him.Always interesting to hear the other side of the story...I appreciate your article "7 mistakes series". I am a Freelancer and have faced all the problems you mentioned in the articles. There are a lot of people on the net who have a couple of dollars and an idea. Most of these buyers post the project on freelancers sites in an anticipation that the project will go perfectly and they will get the program of their dreams despite a very restricted budget. When hiring from India, perhaps they think, India is a poor and crowded country so whatever amount they decide is the right budget for all the features they want. The final result is bad remarks on programmer's skill while he did everything to satisfy his client given the restricted time and budget. I feel very sorry about those Indian Freelancers who get trapped with buyers, who are good at describing a project's requirements in 3 lines on a freelancer's site and then turning it to 3 pages eventually. Anyways, thats really a good effort from you. Keep writing. Thanks, Amit Deo PanwarSounds like a smart programmer to me...check out his site at the link above.Here are the permanent links to the articles "Seven mistakes people make when hiring a programmer":Mistake # 1 - Not Understanding The User's NeedsMistake # 2 - Unreasonable ExpectationsMistake # 3 - Underestimating the Size of the ProjectMistake # 4 - No Shared Vision with the DeveloperMistake # 5 - Rushing Through the Planning StagesMistake # 6 - Letting the Programmer Manage the ProjectMistake # 7 - Not Testing Early, Often, or CorrectlyPosted by Richard on February 9, 2006 12:05 AM| Comments (1)Permalink: Interesting Comments on the Seven Mistakes when Hiring a ProgrammerDon't Let Your Web Designer Own Your Domain NameWhen non-technical people get a website made for them, they sometimes fall into the trap of not getting ownership of their domain name and control of the web hosting account.Here is a case that I just recently saw. I'm having a driveway gate installed so our kids can play on the driveway without worries about them running into the street.The gate man we hired has a web site, so I started asking a few questions about it.I learned that he wants to make some changes, but the person that created the site is not returning gate man's calls or emails. I checked the domain, and sure enough, it was registered to someone else, so I explained to my gate guy why he really needs to own the domain name.If someone else owns your domain name, you can end up with it on all your business cards, have customers using it, then suddenly have the domain name taken away from you.Our gate guy was lucky, because it turns out his domain was registered by his brother-in-law, so domain ownership was easily transferred.When you outsource web design, be sure that you setup the hosting account and register the domain yourself. This way the bills come to you for hosting so no one pulls the plug on your hosting for lack of payment and you own the domain name.At a minimum, you need to be sure the hosting bills come to you and that the domain name is registered to your name before you make the final payment to your web designer.Posted by Richard on December 31, 2005 01:11 AM| Comments (0)Permalink: Don't Let Your Web Designer Own Your Domain NameNew Series on Hiring Web and Graphic DesignersAfter a long time away working on other projects, I'm back and preparing a new series of articles that will help you learn how to hire Web Designers or Graphic Designers.This series will show real world examples to help you be successfull with your first project.Posted by Richard on August 23, 2005 01:26 AM| Comments (0)Permalink: New Series on Hiring Web and Graphic DesignersFreelance Software Development Mistake # 7 - Not Testing Early, Often, or CorrectlyTesting is one of the most important, yet often overlooked activities on a software project. How the test process is handled can make or break a project.Here are a few "golden rules" of software testing.Programmers can't test their own work. It is the same as proof reading a letter you write, you just don't see the mistakes that others find.All software has bugs, some are just not found yet. Some bugs have been found, but not worth fixing because they are minor annoyances that are hard to fix, or will very rarely be seen (we just end up calling those "features" ;-).In the process of fixing bugs, even the best programmers for hire can introduce new bugs.This is why a feature that worked in the last version may not work in a new version. Your test plan must account for this, it's a fact of life with software.It does not matter how simple the change was or what the programmer tells you, fixes introduce new bugs more often than not.The earlier a bug is found in the project cycle, the cheaper it is to fix. Here is an example:John finds a missing feature while writing up his project description (one could argue this is a bug). To fix this, he simply adds another sentence or two to his description.That was easy!Two months later, John finds that one feature has a bug that makes it cumbersome to use with another feature. Since both features are already coded, changes must be made to two places in the code.The changes will introduce new bugs and the code that was "done" will have to be changed again.That was somewhat painful.Two months later, one of John's users finds another bug. Now the program is in production. There is "live data" managed by the program and the shipping department is totally dependent on the program for their operation.Now it is risky to make the fix, down time has to be scheduled, new freelance programmers may need to be hired, and they will need time to learn the original freelancer's unique programming quirks.Now it's really painful!As time passes, pain and expense to fix a bug increase.Lesson: Test early, test often, test everything!Testing is not as effective when done haphazardly. You really need to create a test plan and follow it for each version.Your test plan should focus on the most important features of the program.You should account for which areas of the program are changing with each release and which features are ready for testing for the first time. These areas should get most of your attention when testing preliminary versions.You need to track what you test. Keep notes as you test so you will be able to refer to them when a problem occurs.The most important thing to tell the programmer is what you did right before you saw a bug. This is very important in helping the programmer locate and correct issues.Bottom line: Test early, test often, test everything you can on every preliminary version, and keep a log of your testing.That's it for the seven mistakes. I hope you won't be making any of those mistakes on your projects!I'd really like to hear from you. If you don't mind, take a minute to fill out the Topic Suggestions Form telling me what you think of the Seven Mistakes series and what other topics you'd like to see covered in the future.Posted by Richard on May 15, 2005 03:05 PM| Comments (0)Permalink: Freelance Software Development Mistake # 7 - Not Testing Early, Often, or CorrectlyFreelance Software Development Mistake # 6 - Letting the Programmer Manage the ProjectFreelance programmers like to do programming - most of them dislike project management. Someone needs to manage the project, so that's gonna be your job.Most people that make this mistake do it by default. They don't seem to realize that there is a manager role in the deal.No matter how uncomfortable managing a software project makes you, the reality is it has to be done, and it has to be done by you.Some non-technical people are very scared by this. Remember, you don't have to understand the technology, you just have to understand the problem you are trying to solve and know whether the problem is solved by the program delivered. It's the programmer's job to understand how to use technology to solve the problem. That is why you hire freelance programmers, to get skills you need but don't have."After I described the program I need and I hire a programmer, what else is there to do?"Plenty!You need to make sure the programmer interpreted your description the way you intended.You need to make sure the programmer delivers what you asked for.You need to set expectations and inspect the programmer's work to make sure it meets your needs and quality standards.If something turns out to be much harder than expected, or does not work out exactly as planned, you might need to decide which of several paths the project should take.Here's why freelance programmers should not manage projects:It is your project! You have the final say about what the project is. Giving that job to the programmer is like letting the fox guard the hen house (no, I'm not saying that programmers are sly like foxes, many just need to be properly managed).Programmer do not know the intimate details of your business, your users, etc. You have to provide direction, programmers create software from that direction.An old expression says you only have the right to expect what you inspect. You have to be involved in the project to make sure it delivers what you need.Bottom line: You are the project manager, you must take on the responsibilities that come with the job.That's all for now, next time we'll cover Mistake #7, the common mistake that causes project problems to go unnoticed.Posted by Richard on May 6, 2005 12:23 AM| Comments (0)Permalink: Freelance Software Development Mistake # 6 - Letting the Programmer Manage the ProjectFreelance Software Development Mistake # 5 - Rushing Through the Planning StagesStarting a new project is always exciting. There's lots of anticipation and hope for great things to come. There also tends to be a good amount of optimism at the beginning of a project.Sometimes a bit too much optimism!Some people tend to get caught up in all these emotions. It seems like nothing can go wrong.This makes it a very dangerous time.All the feelings mentioned above tend to cloud thinking and lead people to rush through the early project steps.This is a huge problem, because the beginning stages of a software project are critical to its long term success.It's like laying the foundation of a building; seems boring and slow, but it's incredibly important to get it right.As a project progresses, your options become more limited, so the best time to make choices is at the very beginning. The choices you make at the very beginning are usually the hardest to change later.Here's an example that shows why software projects work this way.Imagine you are starting a new software project. There's a great feature that will make a big difference in your project, but you haven't thought of yet. Watch how much more painful it gets as you discover the need for the feature later in the project.Imagine you think of the feature while writing your project description. This is pretty easy, you just add another paragraph or so to describe the feature.Imagine you think of the feature after putting your project out for bid. Now you have to change your bid request and get programmers to look at it all over again.What if you've already selected a programmer? Now you have to renegotiate the new feature with your programmer (no bidding, just you and him).What if your programmer is already half way through the project? To add the feature, he may have to re-write part of the program to add the new feature, so you'll pay twice for that part of the program.What if the project is finished and already working? Let's imagine it's up on the web, working beautifully. Now you have to do a complete project to get the change done. Worse, you have to account for upgrading the system, avoiding any data loss during the upgrade, minimizing the downtime on the upgrade, etc.Bottom line: don't rush through the planning stages, getting it right the first time is much easier and cheaper.Word of caution: you also need to avoid the other extreme; analysis paralysis (all thinking and no doing).That's all for now, next we'll look at Mistake #6, which is easy to fall into, and hands control of your project to the wrong person.Posted by Richard on May 3, 2005 12:46 AM| Comments (0)Permalink: Freelance Software Development Mistake # 5 - Rushing Through the Planning StagesFreelance Software Development Mistake # 4 - No Shared Vision with the DeveloperHave you ever joined a project that has already started, but is still in the early stages of work? That can be a very confusing time for any project, but especially a software project. It's a lot like when the police arrive at the scene of a car accident. There's one event, five witnesses, and three stories.Unfortunately, many times the early stages of a software project are like that too.People new to software development are often amazed at how many different intrepretations hired developers can get from one document. Same is true of one paragraph or one sentence. Let's see what we can do to keep our projects from looking like that accident scene.When they hire a freelance developer, most people answer the developer's questions about the project and assume that if he doesn't ask a question about a particular part of the project, everything must be OK; time to start coding!If only!What did they miss? They missed all the assumptions:Assumptions made when writing the project descriptionAssumptions the developer made when he read the descriptionHuman nature makes it easy to fall into this trap. After all, you wrote everything down, checked it over carefully, and probably even got someone else to look it over for you.One problem is that we tend to write from our own perspective, not even realizing the assumptions we make. The person that checked your work probably has a very similar perspective to you, so it's not as helpful as you would like.Look, you know your business inside and out, but your software developer probably won't know anything about it. Just think about all the things you do in auto pilot every day. How long would it take to explain all those things to someone new to your field? How many of the finer details would you forget to mention the first time?OK, so how to solve or avoid this issue?Be very clear and concise in your project description. Keep it brief and focused. Adding more words often just adds chances for different intrepretations.Ask the developer some probing questions about the most important parts of the project. You will likely discover some assumptions that you or the developer are making.Get some interesting or useful work output from the developer as early as possible.For example, with a web developer, you might want to see what the pages will look like and how users surf from one to the next early in the project, before the back end code is written.This allows you to make sure everything you need is included on the site and the flow meets your business needs.Caution: don't ask your developer to do busy work in an attempt to make sure he understands the project. Examine early outputs of the real project, not something built just to prove the project is understood.If you can't have a phone conversation with the web developer, it is a good idea to have him create a brief, written design document. You can review this document and look for areas that raise questions.If your freelance developer is in India, stay up late and talk with him at night. If you can't call by phone, use instant messenger to chat. Save the content of the chat and mail it to him for future reference.Bottom line: you have to be creative in how to communicate with your developer. If you don't spend time building a common vision for the project at the outset, you will find differences later in the project...when it might be expensive or too late to change.That's all for this time, next we'll look at Mistake #5, where our excitement and optimism gets us into big trouble.Posted by Richard on April 29, 2005 05:41 PM| Comments (0)Permalink: Freelance Software Development Mistake # 4 - No Shared Vision with the DeveloperFreelance Software Development Mistake # 3 - Underestimating the Size of the ProjectPaul is an old friend of mine from college. He's always looking for an angle to get more than he really has coming.A few months ago, Paul called me to say he was trying his hand at outsource software development. He was trying to get some free consulting from me, but that's typical.It turns out, both Paul and the programmer he hired just figured out they underestimated the size of the project by a good bit.I could tell Paul was excited but worried at the same time. He figured the programmer was over a barrel and would have to deliver. After all, programmers work hard to build a good reputation on the freelance site(s) where they get their work.Still, Paul was worried, but could not put his finger on the reason. He figured there had to be some sort of down side, but couldn't see it.Paul was right, this was not good situation for him or the programmer.Here are some of the possible outcomes from this:1) The freelance programmer sticks with it and gets the job done. If this happens and you don't reward him with a bonus, you're going to end up with a bad reputation as a buyer.2) The freelance programmer cuts corners to finish up and move on to another project. This can be OK, as long as everyone agrees on which corners to cut. It can be really bad if the corners cut are randomly picked by the programmer.3) The buyer and the freelance programmer renegotiate on the project and arrive at a mutually acceptable price/feature balance. You probably only want to do this if you have good experience with the programmer and are pretty far into the project.4) The freelance programmer may just give up on the project if it seems hopeless. In this case, you just have to start all over.You need to learn to estimate the size of software projects. It takes time and experience to learn this skill, but it's worth the trouble if you plan to do several projects. Now, you don't have to estimate down to the day, just getting a general sense of how long something might take is good enough.Any good freelance auction/bid site will help you through this the first couple of times. Just contact the site's support and send them your project description. They can tell you roughly what it should cost.This is especially true of sites that require you to put your project into small, medium, or large "buckets" based on project cost.So how did Paul get into the situation above? He took the lowest bid from an inexperienced programmer.How did things work out for Paul?He had mixed results. Paul pushed the programmer to finish the project. He did save a few dollars, even after giving a small bonus to the programmer. But the program did not really meet expecations.Just goes to show, you get what you pay for.Overall, Paul would have been better off to pay a bit more for work properly estimated. That way, he would get what he wanted from the programmer, not what he could get out of him.That's all for now, next time we'll look at Mistake #4, it's a natural trap for anyone excited about their new software project.Posted by Richard on April 18, 2005 11:08 PM| Comments (0)Permalink: Freelance Software Development Mistake # 3 - Underestimating the Size of the ProjectFreelance Software Development Mistake # 2 - Unreasonable ExpectationsThis is the most common mistake people new to software projects make. Unreasonable expectations lead to despair and failure.OK, so what are some examples of unreasonable expectations?Lots of people expect to just write down a few general ideas about what they want a program to do, put it up for bid on a freelance auction site, pick a programmer, then sit back and wait for the finished product.Unfortunately, it's just not that simple. You need to put time and effort into planning, managing, and testing your software to get exactly what you want.Hiring a freelance programmer is not "fire and forget" technology like a cruise missile fired at a land target from a ship. It is more like a battle tank that needs to be driven onto the battle field, properly positioned in formation, aimed at the enemy and fired at the right instant. To succeed, you need to be involved in the process.Some people plan their project carefully and then expect everything to go exactly as planned. If only it were so!Surprises are the nature of the beast with software projects.Some features turn out to be impractical; some "easy" features take forever to get right; some "difficult" features turn out to be no problem at all (just don't bet the farm on it).You must be prepared, determined, and flexible to complete a good-sized software development project.Some people expect to hit an out of the park home run on their first project. Not likely!You should start with something small and easy to manage. Software projects get much more difficult with size, so get some experience the easy (and inexpensive) way. Starting with a large project is a painful way to learn how to manage a software project.You probably have at least one small project you want done; perhaps a new look for your web site, or a PHP script to generate reports from your site's database.Even if you were thinking of doing the project yourself, it's a perfect candidate to outsource. This allows you to learn the ropes on a project you fully understand. It also frees your time for other more important or more profitable tasks (most likely the reason the project is not already done ;-).Some people expect a single programmer to create software as feature rich as their word processor, for the same price, or maybe even lower if they get one of those guys from India.Well, that word processor was developed by a major company with a team of over a hundred programmers working to create and maintain all those features. They have been working on the same program for years.Obviously, a freelance programmer is not going to crank out as much code as a huge team of programmers.The word processor's price is low because the companies that develop them sell millions of copies (hmmm, not a bad business, eh?).For the specific software you want, the market is more limited. Perhaps you are the only one willing to buy it, so you have to foot the entire bill.What a freelance programmer can do very well is write a custom application to solve a specific problem for you. Big software companies can't compete on that, because they can't sell millions of copies of your custom program.That's all for now, next time we'll look at Mistake #3, one that gets experienced people as bad (or worse) than newbies.Posted by Richard on April 13, 2005 11:54 PM| Comments (0)Permalink: Freelance Software Development Mistake # 2 - Unreasonable ExpectationsFreelance Software Development Mistake # 1 - Not Understanding The User's NeedsThis is one killer mistake! Some people take the "if you build it they will come" approach to software projects. Sorry, that only works in the movies. Those projects are a total flop because they don't deliver what users want or need.To avoid this mistake, you need to spend some time up front getting to know the people that will use your software. This is the only way to be sure that you will know exactly what your program should do.If this seems obvious, read on; most people don't take it anywhere near far enough.Knowing your users gives you key ideas so your program can exceed their expectations. You need to know:What users expect the software to do for themWhat they expect to inputWhat kind of output they expectWhat they will do with the outputHow the user will interact with the programHow the program fits into the real worldYou need to understand the problem you are solving better than most users do. You get to that point by talking with lots of users.OK, let's take a look at how things go when you talk with 10 users. Here's how it usually breaks down:About three of the ten users are a complete waste of time. They don't really think about the world around them, or don't care to share their thoughts with you. Once you are sure someone falls into this group, end the conversation politely, but quickly.About four of the ten will give you good information, stuff you need to know. Some have a slightly different take on certain issues. Most tell you the same thing as others. This group will give you a solid background on the basic features your program needs to include.The remaining three will give you some breakthrough ideas, or trigger awesome ideas based on what you learned from the other seven. This is like striking gold!Just imagine what the other seven users (that's 70% of your user base) will think when you create a program with breakthrough features that blows away their expectations.Now there's a path to success!One word of caution, when you talk with users, sometimes you run head-on into a rant. Some people can really unload on you.Don't take it personally, TAKE NOTES!When people get that exercised by a discussion, you've found an opportunity to solve a problem that is important to them.A guy I know, we'll call him Pete, refuses to talk with users saying "What does Joe know anyway? He just works in shipping."Huge mistake!Joe knows the time consuming tasks that the computer should be doing for him.Joe knows the jobs that are left undone (or get done poorly) because they are a pain.Joe knows the most efficient sequence of steps to get something shipped.Joe knows a lot of things that don't hit the radar of anyone not directly involved in shipping.Now, Joe may not be able to come out and explain all the above points clearly, but I bet you can get the scoop from him over a cup of coffee. It's easy enough to organize what you learn into a useful form.Even if you don't learn anything from Joe, you'll at least get his buy in on the project. This is important because you will need cooperation to get your program into operation. Remember, many people are afraid of computers and resist change, you may have to help them through the transition.Another excuse I've heard for not talking with users is "I don't have time for that."All I've got to say on that is if you don't have time to talk with users, where are you going to find the time for a do-over? Save yourself some time, money, and grief and talk with your users the first time around.Bottom line: make your users "king of the feature list." If they don't want a feature, and it's not a hard business requirement, don't waste your time on it, no matter how good an idea anyone else thinks it is.That's all for this time, go talk with your users!Next time we'll cover Mistake Number 2; the one that gets many newbies into big trouble.See you then,RichardPosted by Richard on April 11, 2005 12:08 AM| Comments (2)Permalink: Freelance Software Development Mistake # 1 - Not Understanding The User's NeedsNew Series Coming SoonIn the next couple of days, a new series of articles about working with Freelance Programmers will be posted.The series is about the seven biggest mistakes people make when Hiring Freelance Programmers.Posted by Richard on April 2, 2005 12:34 AM| Comments (0)Permalink: New Series Coming SoonSix Indian BPO firms get Net-MR CertificationNew Dehli: Six Indian companies have joined a select group of certified BPO providers in the world following a certification by GMI, a provider of integrated software and service solutions for market research.Read the entire story on the Silicon India web site.Posted by Richard on March 20, 2005 11:44 PM| Comments (0)Permalink: Six Indian BPO firms get Net-MR CertificationOffshore Outsourcing SurveyThis is just a quick note to let new readers know about the Offshore Outsourcing Survey.This is an effort to gather information and make it available to the survey participants in order to improve the effectiveness of offshore software development.Posted by Richard on March 8, 2005 09:50 PM| Comments (0)Permalink: Offshore Outsourcing SurveyDoes "Business Savvy" Help You in a World of Offshore Outsourcing?Business leaders and IT experts are disputing an emerging trend in the UK that freelance technologists must be “business savvy” in order to remain competitive on the contract and offshore outsourcing market.I'd have to say, it can't hurt, since that was a good resume item before offshore outsourcing was stylish.Read the entire article at www.contractoruk.com.Posted by Richard on February 28, 2005 10:28 PM| Comments (0)Permalink: Does "Business Savvy" Help You in a World of Offshore Outsourcing?Move IT Work to Rural America?Here's an interesting reaction to the trend towards offshore outsourcing. I've run across articles about moving IT work to rural America multiple times, so either it is getting more press than it deserves, or it is a budding trend.Read the article in the Miami Herald.Posted by Richard on February 26, 2005 03:54 PM| Comments (0)Permalink: Move IT Work to Rural America?
With offices in LA, SF, and SD, CRE is the leading provider of
California computer rentals.
CRE covers all of the Golden State with technology rentals including laptops, desktops, and flat panel monitors.
IT Outsourcing - Infrastructure Consulting company.
Outsourcing HomeOutsourcing SurveyOutsourcing NewsOutsourcing BooksOutsourcing ArticlesWrite an ArticleMake a SuggestionAbout This SiteResourcesLinks DirectoryAdd Your LinkSite MapRelevant Link ExchangeSyndicate site (XML).NET and Java Programming ServicesOnline Business DirectoryWeb DirectoryShower FiltersWater FiltersRichard MouserMouser MerchandiseLyret Keep Links 2345678 Articles Articles 2 Medical Career Training |
|
