A few months back Abhi, Eli and I decided to work together on a project. The objective of this project is to develop a text-based, Ruby version of a game called Hunt the Wumpus as a group exercise in order to explore what it would be like to work collaboratively on a programming project and to develop our team-working skills
Hunt the Wumpus is a classic game originally developed by Gregory Yob and was suggested by Chris as a good project for us to work on.
What we've ended up with a few months later is a working game, but with two versions of the code-base:
https://github.com/nerboda/ls-hunt-the-wumpus
https://github.com/superchilled/ls-hunt-the-wumpus
This definitely wasn't our intention at the outset! We thought it might be interesting to talk about the journey that led us to this point and share some of the things we learned along the way.
Eli: So let's just start by saying, it takes practice to work effectively with others. Especially remotely. We were pretty disorganized at the start.
Karl: Yeah, totally. I remember one of our first sessions was basically the three of us just trying to live code some of the functionality for the game in a shared Cloud9 workspace! We had a lot of enthusiasm at that point but were severely lacking direction and structure.
Eli: Probably the biggest challenge in the beginning was making decisions about the project direction and assigning tasks to get the ball rolling.
Karl: I think we had good intentions. Like, we wanted to manage the project in the right way, we just weren't sure how to do that or had no experience of doing that (specifically with regards to managing a software development project). We tried to apply some structure by setting up a Trello board for the project to assign individual tasks and work items, and later on started using a GitHub branch and merge workflow.
Eli: Our original goal was to each be working on our own separate piece of the game.
Karl: I think we did that, to a certain extent, during the early development of the game (the functionality for creating the map and moving the player was created in this way, and we were writing tests for all or methods at this point). Another issue we faced though is the fact that because this was a side-project we all had other priorities. If one or two of us was busy with something else then nothing would happen for a week or two.
Eli: Right, we had the right idea to start. I got impatient and wanted to see a functional game so I jumped ahead. I had fun with it, but it definitely trashed our plan of having an organized distributed workflow.
Karl: I think this development helped in the sense that it added momentum back to the project at a point where it had perhaps stalled, but probably didn't fit in with our initial objectuives of how we wanted to the project to work. It also brought problems of its own with the fact that we now had a working solution but we could see that it needed a lot of refactoring.
Eli: I had all these big ideas about making the classes flexible so you could easily add new hazards that did different things, change the size of the map etc. Oddly, my focus on flexible classes actually turned into fragile classes.
I ended up bending and stretching the code to match the design idea I had come up with prematurely. The barely functioning end result was the opposite of the loosely coupled, easily adaptable set of classes I was going for.
Karl: There was basically this big WumpusGame class that was doing a lot of the work and most of the functionality was really tightly coupled within that. We agreed that we needed to break up this class, but doing so would take a lot of refactoring of the entire program. We found it difficult to find an approach that would let us do that in a way that we could assign tasks and work collaboratively.
Eli: We solved the problem by deciding to develop our own versions of the game from this point and then talking about each others' code during our meetings and helping each other improve our versions.
Karl: Another issue was that our test suite hadn't kept up with the way the app had been developed, which made it more difficult to refactor confidently. At this point we pretty much reverted to testing the game by playing it!
Eli: Even on small projects like this, writing tests can be helpful. If you are going to write tests, you really should write them first!
Karl: The position we'd found ourselves in prior to making the decision to split off into two different code-bases was also making it hard for us to make design decisions about the app.
Eli: Weighing out the trade-offs of design decisions is equally fun and horrible. Where should this functionality go? Should we add another class for this? A module? Which classes should reach into other classes? What are the repercussions? All scary stuff.
Karl: We knew that refactoring the app was going to be difficult. I think the decision to both work on separate solutions helped in the sense that we were able to be more open in our reviews and critiques. Since at that point we were working from a code-base that Eli had largely developed it might have been difficult to be honest about wanting to change large portions of it had we continued taking the same code-base forward together. Being able to review/ critique openly and honestly helped with being able to make the design decisions that we needed to.
Eli: Something we all knew before but definitely became more apparent through this project is the importance of voicing your honest opinions of other's code. And on the flip side, being willing to accept a straight forward critique of your code.
Karl: I think another thing that helped was that by this point we knew each other well enough to not be too worried about critiquing each others' code
Eli: Right, I actually thought we were all pretty willing to voice and receive opposing views right from the start. Where we might not have done so well is in deciding which route to take when two different opinions both seemed good enough.
[Does that make sense? Thoughts Karl?]
Karl: There's definitely been a lot of learning points from this process. I think we could all have developed this game indivudually in a lot less time, but that kind of wasn't the point of what we were trying to do. One of my main take-aways is about how difficult it is to work on a programming project collaboratively. In retrospect, I think one thing that would have really helped would be to have more clearly defined roles within the team.
Eli: Agreed. Having someone take the reigns as a team lead might have kept things moving along at a better pace.
Karl: I think we did talk at one point about assigning roles but for some reason it didn't really happen. I also agree that having someone to set direction/ take a lead would probably have been beneficial. I'm generally a fan of flat/ non-hierarchical structures but there are definite down-sides to that kind of approach - especially in the early stages of a project.
Eli: I'm looking forward to collaborating with you guys again in the future and finding out first-hand some of the pros and cons of different approaches.