When we came up with our team standards, my team all agreed that Discord would be our preferred communication platform, as we were all quite familiar with it. We also all met in the Unofficial OSU Postbacc Discord server, so it just made sense. We also decided that primarily asynchronous communication, mostly chat, would be our primary way of communicating, while also meeting synchronously when it makes sense to do so–whether that’s for working on write-ups for class, or doing some pair programming.
So far, things have been going well in terms of communication with my team. We’ve all been quick to let each other know when we’ve run into issues, and responsive in helping each other find solutions.
A couple of weeks ago, I ran into issues trying to build our project, because I have a Windows machine, and my phone is iOS. I let my group know as soon as possible that I was going to have to find some sort of solution. I let them know the two ideas that I’d try first, and they gave me a couple of other ideas that I hadn’t thought of. After a lot of research and experimentation… and a few hours with my roommate’s macbook, I was able to get Unity’s Cloud Build service working, and I finally got the build on my phone!
At another point, one of my team members was running into a bug with the specific version of Unity we were using. He let us know that the best solution seemed to be downgrading to a different LTS version, at the sacrifice of a couple of features that existed in the version with the bug but not in the LTS version. His quick communication helped us to understand what was going on, and why the change was necessary. It also let us know to wait until the downgrade change was pushed to our main branch before we did anything significant on the project.
Another way in which our communication has been beneficial is our communication around pull requests. Because we have our repository set up so that a pull request requires at least one other team member’s approval before it can be merged, it’s important that we know when these pull requests happen. I personally like to assign the PR to both of my team members, so that they get a notification from GitHub, but I’ll also send a message in our chat about it. Whoever is first available can then take a look. Doing it this way has helped the PR/code review/merge workflow to be much faster.
The stage that our project is at currently is very interconnected, and that’s a challenge that we’re currently working on. One of us is working on writing the Snake game logic, while another is working on implementing interactive objects attached to an AR marker, while I’m working on implementing the menus and UI to make those interactions possible. This left us at a bit of an impasse, where nobody wants to push code for fear of breaking each others’ parts, duplicating work, or causing complex merge conflicts. The solution we’ve arrived at is pair programming. Once we all have a good idea of what our part should look like, we can meet up synchronously and integrate it together. We plan to do some of that this weekend.
This project has definitely been a bit of a learning curve, but I’ve been enjoying it so far. I wholeheartedly believe we’ll be able to successfully implement what we set out to do, and I can’t wait to see it when we get there!
Leave a Reply