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

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.

That’s all for this time, next we’ll look at Mistake #5, where our excitement and optimism gets us into big trouble.

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.

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.

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.

That’s all for now, next time we’ll look at Mistake #3, one that gets experienced people as bad (or worse) than newbies.

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!

Next time we’ll cover Mistake Number 2; the one that gets many newbies into big trouble.