Key Points to Remember When You Want to Hire Software Developers

Key Points to Remember When You Want to Hire Software Developers

From an article on how to hire software developers ~

“Seven mistakes people make when hiring a programmer”:

Mistake # 1 – Not Understanding The User’s Needs

Mistake # 2 – Unreasonable Expectations

Mistake # 3 – Underestimating the Size of the Project

Mistake # 4 – No Shared Vision with the Developer

Mistake # 5 – Rushing Through the Planning Stages

Mistake # 6 – Letting the Programmer Manage the Project

Mistake # 7 – Not Testing Early, Often, or Correctly

In the fashion of Dave Letterman’s Late Night TV Show, we’ll go in reverse order:

Freelance Software Development Mistake # 7 – Not Testing Early, Often, or Correctly

Testing 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.

Freelance Software Development Mistake # 6 – Letting the Programmer Manage the Project

Freelance 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.

Freelance Software Development Mistake # 5 – Rushing Through the Planning Stages

Starting 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).

Freelance Software Development Mistake # 4 – No Shared Vision with the Developer

Have 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 description
• Assumptions the developer made when he read the description

Human 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.

Freelance Software Development Mistake # 3 – Underestimating the Size of the Project

Paul 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.

Freelance Software Development Mistake # 2 – Unreasonable Expectations

This 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.

Freelance Software Development Mistake # 1 – Not Understanding The User’s Needs

This 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 them
• What they expect to input
• What kind of output they expect
• What they will do with the output
• How the user will interact with the program
• How the program fits into the real world

You 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!

http://www.OffshoreSoftwareSuccess.com