A blog created for CSCI 3081 writing assignments.

The software development processes are many and varied, each method involving taking advantage of its unique strengths while leaving the user vulnerable to its shortcomings and weaknesses. It is up to the developers to decide which approach to software development is best for their situation.

How, then, do we decide? We must first take into consideration how many developers are on the team, the scale and nature of the project to be undertaken, the preferences and past experience of the programmers that will be doing the majority of the work, and the specifications laid out by the team's employer or instructor. For Iteration 1 of the project for our class, this depended greatly on my partner and myself.

We analyzed each of these points as well as many others when deciding on the approach that we thought would be best. It's important to understand the various strengths that can be gained from working in a team and then devise a strategy to bring them to bear as efficiently as possible. One such strength is the ability to, when all team members thoroughly understand their designated tasks, divide and conquer. Each programmer can be working on a specific task that, while alone is only a small part of the greater whole, when combined with the pieces of the others forms a cohesive and functional program. This allows for large pieces of software to be developed quite quickly. Another such strength is the vast amount of collective knowledge and experience that can be brought to bear when dealing with a problem. That extensive reservoir of knowledge will most likely contain the solution to the very difficulty you currently face.

So, taking into consideration all these things, we decided that, due to the fact that this project is split up into iterations, we settled on an iterative approach with emphasis on the divide-and-conquer ability that was afforded us by our partnership.

There were two major parts to Iteration 1 that were easily identified. Taking into account the past experiences of my partner and myself as well as our individual desires to better our abilities in certain areas, we divided up the tasks. I focused on writing the Scanner class and the scan() method while my partner focused on writing all of the individual regexes and properly testing them. This worked well because of my experience writing complex processes and algorithms and his desire to better his testing practices.

When we ran into problems, we forsook the divide-and-conquer method temporarily while deciding on the best way to solve the problem. For example, when writing the Scanner class, I ran into the potential problem of the keyword regexes matching variable name regexes. We stopped our work and discussed possible solutions. We eventually decided that the longest regex to match would be the one that we wanted to match. Once we devised this solution, we split up again and I modified my code to track the longest regex match.

This division of labor worked extremely well and there was nothing in particular that didn't really work out about it.

Working in pairs was a thoroughly enjoyable experience. I have been an iOS developer for coming up on three years now and I have completed all of my projects on my own. It absolutely amazed me how quickly my partner were able to write all the code for the project. Watching the project come together so quickly was exhilarating to say the very least.

In addition to the speed at which the project progressed, there is something psychologically uplifting when working on a difficult project with another person. There's a certain connection with that person that is forged and developed. That person shares in your triumphs, helps you through your shortcomings and failures, and eventually stands alongside you when you present your finished project, the final result of your combined efforts. It's something that is hard to describe in words, but is unforgettable once experienced.

For upcoming iterations, I plan on using the same method we used for Iteration 1, though slightly modified to fit the specifications of the iteration in question. It just seems that our method worked so well, there is very little reason to change. We successfully and properly employed the strengths of our situation while using each others' skills and experience to minimize the potential weaknesses of the iterative approach.