7 Mistakes When Hiring Programmer
Mistake #1: Not Keeping The End User in Mind
One of the biggest mistakes that people and companies make in software development is that they forget that they should ultimately be working for the end user. It doesn't matter how fancy and tech-savvy your software is if it doesn't meet the needs and expectations of the people who will be using it.
The best way to avoid making this mistake is to become intimately familiar with the people who will use the software program you're developing, well before you ever begin writing code. Speak with and listen to the end users, because they are the ones who can tell you what your application needs to be able to do. This may seem obvious, but too often people overlook this important step in any software development project.
Before you begin developing the software, you must be able to answer the following questions:
- What do the users think the software should be able to do?
- What role and applications will the software have?
- In what ways will the users interact with the software?
- What information do your users plan to enter into the program?
- What type of information, and in what format, do they expect to get back?
- How will the users use the resulting information?
You should speak with as many users as possible to get diverse perspectives. You must fully understand the problem that the software is meant to address, even better than the end users do.
Whatever the project is, for every 100 users you speak with, you can expect to receive more or less the same responses:
- Approximately 30 of them will be reluctant to share their ideas with you and you'll quickly identify them as being unhelpful. End the conversation as quickly as possible.
- Around 40 of them will provide helpful information, with slightly varying perspectives, but they'll mostly say the same thing. This is the group that will give you a solid understanding of what basic functionality the software will need to have.
- The rest of the 30 users you speak with will be your favorites. Either they will have brilliant ideas, or they will say something that helps you come up with a brilliant idea. These people are the ones who make it worthwhile to speak with all of the other end users. The features that this group helps you create will really sell your software program to the rest of the market.
Sometimes you'll run across a user who carries a grudge about an existing software program and sees your mini-interview as an opportunity to rant and rave. Avoid the pitfall of taking the criticism personally. Instead listen carefully, trying to pick out the gems of wisdom. If the user is this worked up about something, then this is a sign that you could have incredible success if you can build a software program with an adequate solution for the source of his or her frustration.
Mistake #2: Expecting The Impossible
People who are relatively new to the word of software development often undertake projects that promise the impossible and simply aren't feasible. Or, they expect that the software developers will be able to read their minds. These are classic setups for failure, depression, and despair.
Sometimes people type up some scattered big-picture ideas about how they want the software to work and assume that once they pick an offshore software developer they can relax and wait to receiving the program that magically meets all their needs. Unfortunately, this is extremely unlikely.
If you want a program that meets your expectations, you have to take the time to detail and explain what those expectations are. Your investment in planning and testing the software is directly correlated with how well the finished product will match your expectations.
Even if you take the time to carefully develop a detailed plan, you cannot hire an offshore software developer and expect things to magically work out as you hope. You must give the developer the necessary tools and guidance at the right time and in the right manner. In short, you must be involved in the software development process.
There are always unexpected surprises. The things that should be easiest sometimes end up taking the longest, while some of the most complicated components are finished in a matter of hours or days. And some features have to be abandoned altogether because they simply aren't practical. You must have flexibility, perseverance, and the right attitude to overcome these obstacles.
It takes time to become comfortable with the twists and turns of software development projects. Try to start with a relatively easy, small project and slowly build up in complexity and size over time. You might even want to try outsourcing a project that you were planning to do in-house, so that you can monitor the outsourcing relationship on a project that you already understand. If you follow this advice, by the time you're outsourcing expensive, high-risk projects, you'll have gained the experience you need to manage them correctly and efficiently.
Another unrealistic expectation of many newcomers to the world of software development is about the amount of work that one programmer can realistically do. Many people expect to get a program comparable to an elaborate spreadsheet program or word processor by contracting a single programmer. Rarely do they realize that such programs are developed over many years or decades by large teams funded my major multinational corporations. It is neither realistic nor fair to expect a single person to produce anything near that volume and quality of code on a single project.
Also, many people balk at the price of software development projects. They're used to the relatively inexpensive price tags on store shelves, but those prices are low because millions of copies of those programs are sold around the world. In contrast, you are probably the only customer for the software development project that you're contracting and, consequently, you will have to bear the total costs of creation.
Rather than asking a programmer to develop a new software program from scratch, try asking him or her to write a customized application that addresses one of your specific problems with an existing software program. This is the type of work where these individual programmers thrive, and larger companies that rely on bulk sales simply cannot compete with them.
Mistake #3: Thinking Your Project is Smaller or Easier Than It Really is
Many people have a tendency to underestimate the size of their projects. When that happens, one of the following four things may result:
- The programmer puts his or her nose to the grindstone and finishes the work, but holds a grudge against you. Unless you offer a hefty bonus for going above and beyond the call of duty, you're likely to become known as a bad buyer.
- The programmer rushes to finish the project, cutting corners and giving you a slightly sub-standard project. Sometimes this is okay if you have a say in which pieces can be shortened or eliminated, but if the programmer alone picks them, chances are that you'll be disappointed with the final outcome.
- Once the project's true size becomes apparent, you and the programmer renegotiate the project specifications, timeline, and price. This isn't likely to happen unless you already have a long-term professional relationship with the programmer.
- The programmer will change his or her mind and decide not to finish the project, forcing you to select another offshore software developer.
Estimating how big your software projects are (that is, how long it will take to complete them) requires significant experience and time, but if you're going to do many long-term software development projects, this investment of time and energy is well worth the effort.
Your estimate doesn't have to be exact, but you do need to have a pretty good idea of approximately how long it will take a programmer to finish the work. If you're uploading your project description for online bidding, the technical support staff at the bidding website should be able to help you develop a fairly accurate estimate – especially if their site requires placing the project into one of a few budget ranges. You can also browse similar projects on the site to get a feel for appropriate time estimates and prices.
Mistake #4: Not Sharing a Vision With The Programmer
A project description, or even one section or word of that document, can be interpreted in a surprisingly large number of ways. Particularly in the early stages of a project, these differences in interpreting the scope of work can lead to confusion and chaos, with the project starting out in an entirely different direction than what you had envisioned.
That's why it's so important to share your vision with the programmer and make sure that he or she truly grasps what you're trying to accomplish. Too often, people discuss their projects with the selected programmer and assume that if he or she doesn't ask questions about a particular component of the project, it must be understood. That can be a serious mistake.
The programmer's understanding (and yours) of the project is always based on assumptions. You made assumptions while creating the project description, and the offshore software developer made assumptions while reading what you wrote. It doesn't matter how many revisions you went through or how explicit you have tried to be. Those assumptions color our interpretation of the project, often so much so that we are unaware of our own assumptions. And even if you sent your project description out for review, you probably sent it to someone who had similar assumptions and therefore didn't catch them either.
You have extensive knowledge about your business and the environment in which it operates, which is the basis for determine what type of software you need. You are responsible for conveying that information to your software developer. Here are a few tips for helping your developer understand what you're after:
- Write your project description clearly and concisely. Although some people think that more words add concrete detail, often they have the opposite effect by providing more opportunities for different interpretations (and misinterpretations).
- Ask the programmer questions about your project and see how he or she rephrases the tasks in his or her own words. This is a good way to uncover the programmer's hidden assumptions.
- Ask for deliverables early and often. That way, if things are going off track, you can correct them before too much time and money is lost. And protect yourself by always asking for and reviewing prototypes or mock-ups before the final coding begins. But make sure that these requests aren't just “busy work” that waste the programmer's time. Make sure that the milestones are truly steps toward completion of the final software program.
- Request that the programmer write a document that describes his or her design concept. Read it carefully. If the vision doesn't match up with yours, discuss the differences with the programmer before work begins.
- Maintain open and frequent communication with the programmer. Even if the developer is located in another country and time zone, you can adjust your schedule to accommodate online or phone meetings. Use Internet tools such as instant messaging to monitor the project's progress, and save those chat files for future reference, sending copies to the programmer.
Getting to the point where you and your programmer share a common vision can be difficult and time-consuming, but it's well worth the effort when it yields the final software program that you were expecting.
Mistake #5: Taking Shortcuts in Planning
When an outsourced software development project begins, it's easy to get caught up in the excitement and anticipation of the new program that's going to be development. But be careful that this excitement doesn't lead to unwarranted optimism, which can make you forget the importance of planning and encourage you to heedlessly rush through the early stages of the project.
Those early stages are absolutely critical to the success of the project. Although planning may seem too slow and boring to be important, without adequate planning the project will fall on its face. Planning is the foundation upon which the rest of the project is built.
Before a project begins, you and your programmer face almost unlimited choices in design and functionality. As soon as the work starts, those options become increasingly limited and it becomes increasingly difficult to change the initial choices that you and your programmer have made. That's why it is so important to getting it right the first time through careful and thorough planning.
If you don't think through your project initially, you may not think of a key feature that would make it a much better solution until a few weeks or months into the project. By then, it may be too late to add that feature, at least without incurring significant expenses and delay. For example, if you think of the idea while you're creating the project description, it's easy to add it in with just a few more lines of descriptive text. If you don't think of the new feature until after you've placed the project description in an online auction, you'll have to revise the request for proposals and all the bidding contractors will have to revise their bids accordingly, meaning that you've wasted your time and theirs. If you have already chosen the programmer you want to work with, you'll have to discuss the new feature with him or her and renegotiate the entire contract, including the cost and timeline. If you don't think of the new feature until your programmer is already well into the development phase, the programmer may be forced to rewrite the code, which means that you'll pay for one or more sections of the program twice. Finally, worst of all, if you come up with the idea for a new feature after the software is already up and running, you might have to create an entirely new project to modify the program, and you'll probably have to worry about transferring the data that's involved and finding a temporary software solution while the program is offline so that changes can be made.
Clearly, it pays to do your planning upfront in terms of time, money, and energy. However, don't become too obsessed with planning, because taken to extremes you may spend all your time planning and never move on to actual implementation.
Mistake #6: Forgetting to be The Project Manager
Outsourcing a project frees up a lot of your time and energy. You have found someone else who has the technical skills to complete your project. But that doesn't mean that you can give the offshore software developer free rein to do as he or she pleases. There must be a project manager, and that person must be you. Even if you don't know a great deal about software development and would prefer to defer to the expert programmer, you must make sure that you – not the software developer – are the manger.
The good news is that to be a good manager you need to understand only the problem that the software is supposed to address – not the underlying technology, because that's the domain of the programmer.
Once you have created an adequate project description and contracted with an offshore service provider, you still have many tasks ahead of you.
- You must discuss the project with the programmer to be sure that you're interpreting the details in the same way and with the same overall vision.
- You must monitor the project and make sure that the programmer promptly meets all milestone delivery points. You must establish clear expectations for quality and evaluate the programmer's work accordingly.
- You must make decisions when obstacles arise and project changes must be implemented in the scope, timeline, and/or budget.
The offshore programmer shouldn't be put in the position of managing your project. Why? Because it's yours. You know what you're looking for in the end, so you're the best person to manage the project's progress toward that end. Also, there's no way for the programmers to know everything about your company, its clients, and the environment in which they interact. You are the expert here, and as the manager you must convey enough of that information to be sure that the final product meets your needs and expectations. Finally, you must be an active manager, because if you aren't you'll have no justification for complaining if and when the final product does not fully meet your needs. You'll have nobody to blame but yourself.
In short, outsourcing a project does not free you from the responsibilities of project management. Embrace those responsibilities and you'll reap the rewards of a well designed software solution that fully meets the needs of your company and your end users.
Mistake #7: Failing to Test The Software Appropriately
When you're outsourcing a software development project, it's easy to focus on development and nothing else. But testing, although too often overlooked, is critical to the success of your project. You must test early, often, and thoroughly.
Programmers should never be put in the position of testing their own programs. Just as you would probably ask a friend of colleague to proofread something you wrote, programmers should ask other programmers to test their work. It's simply easier to find errors in other people's work that in one's own work.
It's important to recognize that virtually all software programs contain bugs, but not all of them need to be worked out. Some are so minor that the cost of fixing them isn't justified, or others appear only very rarely. And of course, there's always the possibility of introducing new bugs when a programmer tries to fix existing bugs, now matter how simple the change appears to be, so sometimes fixing them simply isn't worth the risk.
Before you begin testing, you should have a clear plan in place. It cannot be done in a piecemeal fashion, because you want and need to test every software component. Focus on the most important software features, and especially those that are likely to change in future versions, if that is part of your plan. Also, while you're testing, be sure to record and track the test results so that you can see improvements over time. As you're using the software, take notes of any bugs you encounter, as well as what you were doing immediately before they appeared, because this information will help the program better identify and correct the bugs.