Service with an issue

After tinkering around with some of the different open source projects that I thought was interesting, I had joined a team that was working on adding some functionality to an open source project. The team was made up of people that had different schedules, so face-to-face meetings would be difficult and we would be communicating by e-mails. Using Google code to store and post our project, we started to use issue-driven project management. The project I was working on is an improvement to the WattDepot client called Hale-Aloha-CLI. You can find the project here.

With issue-driven project management, the contributors as well as followers of the project can bring up issues that are specifically posted and noted that document any errors or discrepancies that the project team can focus their work on. By having a steady workflow of solutions that address the problems of fixes of certain issues, a project can identify and fix more problems that can arise during development of a project due to coding errors or other such problems. It is also valuable when the work is divided among several people or groups, so that the work is concentrated with a specific group and any of the other contributing members can post any errors or fixes that they have found.

Our project implemented a command line interface to the WattDepot client, along with several functions that the user could choose from:
1. A current power method that shows the current power in kW for the associated tower or lounge.
2. A daily energy method which shows the energy in kWh used by the tower or lounge for the specified date.
3. An energy sine method which shows the energy used since a specified date until now.
4. A rank towers method which shows a list in sorted order from least to most energy consumed between a starting and ending date.
5. A quit method to end the program.
6. A help method which shows the list of commands to the user.

As our team started using issue-driven project management, we were not fully versed in the technique and stumbled along with the work and issues. Some issues were quite vague, but there were other issues that were very important to the project. After awhile, we got into the routine of posting issues that we are working on or problems that we found to specifically address certain configurations. The routine was the more difficult things to learn because I was used to smaller individual projects that were simple enough to build individually that did not need close interconnections that relied on other components heavily.

We split up the work among the three members and started work on our respective parts. Implementing the different methods for the command line interface was simple, since they were like the katas that I had completed which I posted awhile back. The main program, processor class, and command manager class were the more difficult things to code. I had to code the processor class, which would take in the user input and parse the input then compare it to the list of commands in order to call the correct command. I also created tests for the processor class to catch improper code calls and incorrect number of arguments for a method call. The amount of time needed to code and debug the project took a good amount of time and it wasn't helping when the server that was used to get the sensor information from went down. In the end we did manage to implement all the functionality that we wanted to implement and create tests for all the classes.

I think we were all a bit overconfident about this project and thus communication with the other members of the project was difficult at first, but we quickly were able to work out the problems. We reading the issue listing in Google code, we could post any difficulties or problems that we had and could discuss with the other team members about the solutions to the problems. The whole experience was difficult at first, but the gains that we made were much more than I thought we could make, based on my experience with other group coding projects that were not issue-driven. What I learned from issue-driven project management is the experience and knowledge gained for the workplace which highlights a more interactive coding process with input from other people who are not contributors or coders in order to create a better product from the input of users and programmers.