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.

2 thoughts on “Freelance Software Development Mistake # 4 – No Shared Vision with the Programmer

  1. To write instructions for a programmer to understand and be able to code, you need to use 4 basic elements:
    1) Write instructions in a logical format. This includes using numbered bulleted format. Your description should be logical and step-by-step, in that anyone should read what you say and reach the same destination. Just like if you were to give directions to your house. Anyone who follows your instructions 100% should reach the same destination.
    2) Visual examples. Screenshots, powerpoint, video screen capture or recording of your ideas. Snagit is a great screenshot program where you can quickly mark-up photos to callout or write comments on exactly what you want the programmer to do or what feature you have.
    If there is something in nature or another product that already does what you want to do, no need to re-invent the wheel. Find a way to capture visually what someone else has done and reference that software or action and say “this is similar/exactly/opposite of what I want in this project requirement”
    In some cases yourself or the programmer can create “sub programs” or “mini programs” can be built to display specific functionality to see if
    it is what you want included in the main program.
    3) Milestones or stopping points. Because of the nature of programming, one of the benefits of working from scratch is that once the foundation is coded, you can test each feature or set of features before getting too far in the project.
    This helps the programmer not get to far ahead before making sure the program is up to spec. This also ensures that your project is on a schedule and you can test different functionality to make sure your requirements are met.
    The ideal program will be coded in a way that it can be scaled (features can be easily added to it at a later point).
    4) Continuous communication. Thorough discussion before, during and after project is completed. Be specific in your feedback. Use screenshots and detailed (yet concise) explanations of what you want to see happen, and why the current program is not working.
    Also, it’s not uncommon to come up with additional requirements as the project progresses. For whatever reasons, you want to add or delete features. Communication is the best way to see this through.
    Great article. Communication is the key.

  2. Hello there I am so delighted I found your blog page, I really found you by mistake, while I was researching for something else,
    Regardless I am here now and would just like to say many thanks for a remarkable post and a all round enjoyable blog. Please do keep up the excellent work.

Leave a Reply

Your email address will not be published. Required fields are marked *