No Shared Vision with the Developer

Freelance Software Development Mistake # 4

Source: Offshore Software Success
Author: Richard

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.