A week went by. Since I didn't hear from them, I assumed things were going well. The lab on Monday before the assignment was due, I asked them how their ends were going. Nobody in the group had anything tangible to test, and nobody wrote any tests (including me). So we restructured our work again. This was our second mistake.

I figured we had three basic elements to work on. First, we had to write a scanner. Second, we had to write tests. Third, we had to put everything together and fix bugs. Having three people, this made the logical division of labor to have one person on each of these tasks. One partner would write the scanner, my other partner would write the tests, and I would put it all together. This was our third and biggest mistake.

Like most college students with full time jobs, I was busy. Between Monday and Wednesday, I was either at work, at class, or at home sleeping. I wouldn't be able to work on the project until Wednesday night (the night before it was due). Since all I had to do was put it together and fix a few bugs, I didn't see a problem with this. I will find out later that I was an idiot. What follows next can only be described as quasi-organized chaos.

Wednesday night came along and I went to update my workspace with their additions. I was surprised to find that my repository was up to date. I checked my files and did not find any changes. I emailed my group-mates and asked them if they forgot to commit changes. The person doing the scanner emailed me back and told me that he was working in the tags folder of the repository. He said that he was having problems with C++ classes. To see where we were, I ran the make run-tests command to compile and run our tests (of which we had one to tests 1+2 = 3, just to make sure the tests were working). The compiler gave me several hundred errors. This was where pair programming would have come in handy. In the future, our group will code together. I worked on it for several hours, and I got rid of most of the faults by commenting out much of the code and fixing the classes. It didn't run correctly, but it compiled. By 4 A.M., I decided that I would take a nap and start again after class that day.

At two in the afternoon (t-minus 3 hours until iteration one was due), my partners and I met in the lab and worked on it again. We hurriedly threw together some code. We made sure all of the files were in the right places and handed in what we had. What we handed in for iteration 1 was a failure. What I don't want to do is play a blame game. None of us were prepared for this, and all of us were to blame for the group not succeeding. All we could do was move on to iteration 2.

Some of the mistakes we made were due to inexperience. My partners lacked the coding experience to get the program running, and I lacked the experience to guide them in the right direction. The saying "If I knew then what I know now..." comes to mind. The thing is, we do know now what we didn't know then. We know what doesn't work. We are starting to get to know the people in our group and how we can work together.

One thing that needs to change (and have already started to implement) is the division of labor. Instead of one person assigned to each task, we will have every person do small parts of every task. For iteration 1, this means that all members are involved in writing the Scanner class and the Token class. Then each person can go off and write the code to get several tokens. That person will also write the test cases for those tokens. This way, we are all responsible for the main parts, and each partner can be responsible for small parts of the project as well.

Another aspect of our group that needs to change is communication. We did not talk much during the time leading up to the due date, and this meant that none of us knew where anybody else was in the process. It also meant that if one person got stuck, like in the case of the scanner, the whole project got stuck. What we will do in the future is ask our partners questions when something doesn't make sense and make sure that everyone is on the same page.

The last problem we had was time management. We left very little time in the end to work on this, and it was this problem that really shut our group down. We are not going to make that same mistake twice. Next week is spring break, and I'm going to use the extra time not taken up by pesky things like classes to plan iteration 2 and try to finish it. This will of course depend on my partners being available.

To sum up, the three things that we did poorly were division of labor, communication, and time management. To be successful in iterations 2 and 3, we need to fix these problems. It will take lots of work and coordination from all partners, but it is not an impossible task for us. I believe we are on the way to making something useful. Programming well is more than just knowing how to code; it requires the ability to work as a team.