The Road to Iteration 1

| No Comments

The road to Iteration 1 was paved with good intentions, but was bricked and mortared with bad coding practices and even worse attempts at communication, to create a cobblestone nightmare that scarcely even resembles a unified effort.

This isn't trying to throw my partner under the bus; I was just as responsible for failing to communicate and begin development within a reasonable timeframe. As a result, the both of us spent very little time talking about how to develop the scanner class, let alone the requirements for the whole project iteration.

I'm talking catastrophic failure cross pollinated with the worst kind of communication breakdown, fueled by procrastination and performance anxiety under pressure of deadlines. Besides the obvious problem of starting the night before the due date, several implementation problems resolving in irreconsilable compiler errors might have been easily fixed by simply sitting down, trying to talk out the implementation without writing a single line of code or touching a keyboard, and making sure we both understood how exactly whatever test cases or code we wrote would function, without thinking about it or getting code anxiety from looking at a sea of letters, numbers, and characters and thinking "What am I supposed to be doing here?"

But that didn't happen, just like we didn't really talk about how to code, or what times worked for us, so we wouldn't try to code at the same time and run into bizarre errors from syncing subversion revisions from our respective local copies. There was no structure when it came to organizing our efforts at attacking this problem and constructing anything meaningful.

When we did code, we had the foresight to try and break up what we were working on to avoid svn screaming that we had two different local copies, and try to merge in bizarre and disasterous ways. It didn't matter, my partner and I were on two different wavelengths as far as understanding in covering the program requirements and following a cohesive logic and coding style.

If I wrote the test cases to work by testing individual regexes without any form of a helper function, he would write scanner code that would test the char * buffer against a string compare function.

Frustration abound, we simply let the main bulk of the project fall to the wayside, and tried to salvage what parts of the project we could still receive points on, and recoup the points from test cases and creating functional code later.

Stated clearly, we failed, and hard at that. I can only say that I hope we have learned from our mistakes, and that by some grace, we can communicate in earnest and start establishing an effective workflow, whatever that may be.

To reiterate, I believe the answer is to open up, and communicate on a regular basis, such as communicating changes made directly to the person, as well as providing a rationale for the changes/added code. I believe many of our problems as a group were caused by procrastination, but that was not the main one in my mind.

I felt going back and forth talking to my partner while we were trying to write code, that he did not have a clear mental model of how scanner interacted with the different parts of the program. Any attempt I made to try and explain how I believed the scanner should work was met with silence and trepidation. The result was a number of subroutines within the scan function written before test cases, and could not be tested for functionality, because they resulted in compiler errors.

It would be profoundly narcissistic to say that I am a better coder than him, but I believe much of this problem is rooted in a code phobia or unfamiliarity with effective coding practices, and could not only be eliminated, but reversed if I made attempts to communicate and establish a kind of to-do list for what needs to be understood in each iteration and discuss effective ways to accomplish goals of the class (more than just how to code or functionally diagram pieces of code).

If we, as a group, took a few hours to go over the project and the code we have been given, just to establish a mutual understanding, moving forward through the project would be fantastically simple. Establishing this channel is important for clarifying, critique, and any other relevant communications which might be shared between us.

Besides the obvious need to go back and fix our iteration 1, our group needs to begin aggressively communicating with each other and keeping ourselves accountable for the work we both need to accomplish in order to complete this project.

- Tom Baumgartner
March 8th, 2012

Recent Entries

Find recent content on the main index or look in the archives to find all content.