The Long Distance Developer Relationship

As you may be aware, I am no programmer extraordinaire.  So what is a non-technical co-founder to do when she finds a developer across the pond?  I live in the interior of British Columbia, Canada.  I was extremely fortunate to find a developer who was someone I knew from my undergrad days.  He was excited about our project and had the skills and enthusiasm to push our ideas from thought bubbles to something tangible- so it seemed like a great beginning.

The only problem was that he happened to live 5 hrs and a ferry ride away.  Is it possible to build, develop and change at a distance?  Or is it a nightmare waiting to happen?

For us, it worked really well.  We had our bumps but overall, a positive experience.  Here are some tips and tools for the long-distance developer relationship.

1. Courting

This may seem like an old-fashioned term but I just brought it back to the realm of developer dating.  Our ‘getting to know each other’ dance was initially done over email.  We chatted about the general nature of the project, goals, ambitions, techniques and timelines.  We also determined if our future Code Master was a good fit with our personalities, humour and work style.  Don’t underestimate this.  Creating a viable ecosystem is fundamental for productivity.

2. Love Letters.

Ok – not love letters, but all the necessary documentation for getting your idea imbedded within the mind of a totally non-submersed individual.  Remember, this person doesn’t eat his start-up for breakfast, lunch and dinner like you do.  We created a number of documents to help communicate our vision:

a) Software development agreement– this one may seem obvious but do NOT push forward without it.  Have it worked out and written down.  Comment on who owns what, who’s getting paid what, the payment schedule, post-contract problems etc.

b) Use Case Diagram– We constructed a flow diagram that outlined all of the interactions among the various players.  This is not a document that picks away at the nitty gritty details, but an overall summary of how our end users, clients etc. interact with out product.  We shared both our long-term vision and our MVP.  Our developer only built out the minimum viable product; however, we thought it important to show our future ambitions as we wanted our product to be scalable for the future.

c) Detailed flow of the website, web app etc. – Here’s where you get into the details. We used PowerPoint to create a thorough outline as to how each web page or component connected with each other.  I am dead sure there are better programs out there for this, but it’s what I came up with in a hurry.  Other suggestions are welcome!

d) Payment transaction outline – simply put, how the flow of the money goes.

3. The Third Party

For your experimentalists out there, it’s never too early to bring in another party.  I wish we would have done it sooner.  And when I’m talkn’ 3rd party I don’t mean the hot blonde across the bar- I mean Google Docs.  Why didn’t we do this sooner?  It’s beautiful, really.  I’m sure you are all aware of the slickness of this application, but I will briefly describe below.  We created a couple of key documents that were shared amongst us:

a) Tasks /Bug Tracker – in this spreadsheet, we itemized tasks and bugs that were found throughout development.  It’s all real-time so I could actually see our developer crossing items off the list as they were completed.  I admit, it was a little creepy at first but incredibly helpful in the end.  It gave everyone a sense of what was left to do, what the priority items were and the general progression of building.

b) Q&A– this word document was used to ask general questions about development.  Because I don’t fully understand the difficulty or reason behind some of the processes involved, this document was useful for long, more involved questions.

Having all documentation in one place also gave us a historical record of all things asked, done or commented on- much easier than rooting through old emails.

4. Communication

Perhaps it sounds like old news, but any solid relationship is built on effective communication. Whether you are working with someone who is sitting beside you or at a distance- talking, drawing, writing, storytelling, illustrating is so so important.  This brings me to another really effective tool to help you communicate…

5. Make a Movie

You kinky folk may be snickering out there, but what I mean is harness the power of your smartphone, iPad etc. and upload videos to YouTube to share development bugs or problems.  We found that making a little movie was WAY EASIER than trying to describe it over email or Skype.  Trust me on this one.  I wish we would have done it sooner.

One final note.  It’s really important to have a developer who is flexible and open to change.  Things change… lots– so having someone who understands that is a lovely thing.

Thank-you to our developer who has been a pleasure to work with.  You’ve made our long distance developer relationship worth the distance.

[Photo Credit:]

Leave a Reply

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