Developers Without Borders – A Collaborative Workflow

June 6, 2013

As always with projects, the most important thing is functional communication between all parties involved. Usually you sit near or live near the rest of the people in the project you’re working on. This was not the case with monorun (update Feb 2018, the website has been taken down), even though Carlos and I grew up together in the same town, currently, we both live in different countries, I live in Sweden and he lives in the United Kingdom. Early on in the project we knew we had to have some kind of way to collaborate and keep notes. We took what we’ve learnt from our day-time workplaces and settled for three main components.



As with any project, you need to keep your source code under version control, even though I seldom use the revert-functionality in CVS tools like Git or SVN, it’s always good to keep some kind of history on the files (if for nothing else, historical purposes). I could’ve set up a Git repository as remote on one of my personal servers, but because wasn’t a commercial one, and me and Carlos were the ones planning it, it only felt natural to share the code with the world. When we set up the repository, we had a few basic rules that are fairly common in git-projects, we had two branches, master and dev. The master branch only contains code that have reached a specific milestone, so that code should be considered stable. The dev branch is the working branch, all commits are done there, and when we felt that the code and the features for that milestone was done and stable, we merged the dev branch to the master and tagged the commit with a release number.

Github makes it easy to view and share code from the repository right through the browser, which meant we could more easily post specific commits to each other and talk about different solutions in both the master and dev branch without needing a git client.

Sourcetree in combination with github makes git fairly easy to understand and makes the process of actually cloning and deploying code a lot easier.



The first thing we did after we decided that we were going to create a remake of RedSquare was to jot down the key components of the game, what was needed, how it should work and how it should look, each point was then further broken down to smaller pieces and added to Trello as cards. The cards were then assigned to the person in charge of that “problem”, as I handled the game functionality and backend, I was appointed all those cards, while Carlos took care of the brand, the design and front end code, which meant he got those cards.

The good thing with Trello is that you can easily filter cards to your own name, which makes the project very manageable from a subjective viewpoint. You can add checklists on every card and if a specific point is to big, you can pull that one out of the list and create it’s own card through just one click.

Another useful feature, which admittedly is probably core functionality, is that anybody can assign anyone to any card, which means if somebody found a bug, they could just create a card, with a descriptive explanation of the problem and then assign the card to the correct person.

We both took our own responsibility to prioritize our own cards. This made a lot of sense because I could for example fix bugs on the same time as I was building in that particular place in the code.

What we found with Trello to be especially good, which was more of an accidental thing, was that we only made cards for things that we knew from the get go was going into the game, which meant that we were able to keep feature creep to a minimum. Anybody who has ever worked with me and Carlos can probably attest that we both have a lot of ideas, and sometimes (or usually) it’s kind of hard for us not to come up with more features faster then we are able to implement them, which can end up with a larger scope then initially decided.



Arguably the most important tool that we had was Skype, even though the other tools are good for distributing and documenting different parts of the project, the communication part is still what makes a project successful. We basically kept our lines open as long as we were working on the project, and if we needed to make a decision about something, the other person was usually just a message away. We then had about twice a week a longer phone call where we went through how people had liked the game, which devices that had been tested and if we need to change direction on different parts of the game. I really believe that these phone calls had the largest impact on actually getting things done, because it’s very easy to forget issues that have only been mailed or messaged to the other part, when your actually speaking with someone, you’ll have a better chance to actually understand the depth of the problem, if the problem or bug is actually as crucial as it seemed in the trello-card.