The following blog post aims to answer the questions in the list below.
- What parts of the process worked well?
- What parts of your process did not work so well?
- How was it to work in pairs?
- What will you need to change for the next iteration to be more successful?
- What development practices will you continue to do use?
Recently, with the help of my partner Rich, I completed the first iteration of Computer Science 3081w. In general it worked out extremely well for me and Rich; so, I am going to speak a little bit to what exactly made the first iteration go nicely for my group.
There were a few key things that made the entire process very easy. The first lesson that I learned quickly was, above all else, communicate! I spoke with a few other groups about how their experiences went and the root of success or failure seemed to stem from communication. I've been good friends with my partner for a while, so communication was a natural part of accomplishing our task. Subversion commit messages are simply not enough to communicate adequately to your partner what is going on. Any time I wanted to get some work done or discuss approaches to different parts of the first iteration, I called or text messaged my partner and set up some form of channel of communication. For example, the tests that we had written for our scanner seemed reasonable enough; however, I wanted to take our project's durability to the next level. I knew that it might be tough for me to see ways to break my code, since I'm naturally biased towards believing my code is invincible. So, I called up my partner and asked him to sit down with me and try everything we can to absolutely destroy my creation. Not surprisingly, it turned out that my code was not invincible. We ended up generating a bunch of eve of destruction tests as a result, which will undoubtedly lead to more points being gained on the first iteration. So, lesson number one is always keep communications at a maximum!
Communication was not the only important method that helped the process go smoothly. Another extremely critical part of our first iteration going smoothly was getting together and coding. It's always nice to be able to work from the comfort of your own home and do things on your own terms. Doing this comes at a price, though! We found that when we sat down next to each other and started hashing out design ideas and passing code ideas back and fourth that our project started to have a higher level of cohesion. It increased cohesion between how our scanner interacted with our regular expressions, and how our tests interacted with our scanner to push its limits. The cohesiveness that we achieved could not have been done had we worked over the internet. There's something special to be conveyed about working next to somebody and being able to convey ideas in person. This uniqueness allowed us to make much more efficient use of our time, and undoubtedly will make our project better in the future.
Surprisingly, there were really no parts of the first iteration that did not go well between me and Rich. The only real challenge was understanding specifications, which I don't think was anything that either of us could have done anything about. As an individual who works in the industry, I've never really experienced specifications that were to that degree of vagueness. Whether it was intentional or not, I am sure it exists in some parts of the industry, just not that I have experienced. Either way, this was not a tremendous hurdle and can't be considered too much of a struggle.
An important lesson that this project should have showed everybody is that coding needs to be a social activity. Working in pairs was an absolute joy. As a computer scientist, I like to create a comparison between how the computer works and what working in groups enables. When working alone, you are effective running the same as a processor with just one core. Processes are general sequential and there's little room for heavy optimization. When working in pairs, I feel like our group's effective processor speed was increased as a result of more cores. Sequential techniques became a thing of the past and we were able to efficiently work in parallel, enabling optimal use of time. Just the same with processors, parallel tasks are more challenging to do sometimes. However, the benefits far outweigh the costs. Working in pairs is absolutely critical in my opinion to succeeding in development and in the project.
For the next iteration, we were both quite happy with how things went, so not too much will be changed. Everything went absolutely perfect, so I look to apply the same strategies I applied to the first iteration in order to make the same happen when working on the parser for Iteration 2. I fully intend to have to adapt to a few new ideas on the next iteration, but I do not expect that to be much of a challenge.
There were a few core development techniques that we tried to model our first iteration after, and that I would recommend doing for any general development projects. Some of these practices were:
- Test Driven Development: We created the tests that we set out to pass, and then we passed them. Of course we added more tests afterwards, but we started with this key step.
- Agile Development: Both of us work in the industry in agile studios. Breaking the iteration up into mini, sub-iterations worked amazingly. We will continue to do this as well.
- Social Coding: This may not be an official development "technique," but I believe it to be a valid technique to consider. Everything is better when multiple minds get together. I would highly recommend to any groups working on future projects to immerse themselves in other programmers and engage in this concept that I refer to as "Social Coding."
I look forward to working on the next iteration and learning how to adapt our code to add new components to work with our already existing suite of code. I think that adding in the parser will present some interesting challenges and I look forward to keeping this blog updated on how me and Rich are working to tackle the constant challenge of adding to an existing code-base and making it all work together seamlessly! Until next time!