I'll be frank. This post is not going to be pretty, elegant or overall very fun to read. This is not your fault, readers. I am not punishing you. In fact, this particular entry is being written as a response to a software development project that I was recently and currently involved in. Unfortunately, until 7 hours ago, the project was, more or less, not fully implemented and thus there was a bit of difficulty in gathering my final thoughts on the ultimate experience I wanted to convey.
To be brief, the project's inconsistency most likely stemmed from a difficulty in facilitating an effective line of communication between our team members, likely due to the fact that we are all current college students with too much on our plates and too little time in the day. However, this ultimately resulted in quite a bit of "last minute heroics". I have to admit, I am largely to blame. At the inception of the project, I was full of optimism and may have unwittingly assumed a role of leadership I was not necessarily willing to be in. As a result, as my initial barrage of Emails missed their marks, I let my own failure to "rile up the troops", so to speak, get to me. As a result, my own enthusiasm for the project diminished significantly and now I sit before you in confession of having given up even before the "last minute heroics".
Overall, my experience of issue driven project management was hectic. In theory, it sounds like an amazingly streamlined and intuitive way of solving the project management problem. However, in practice, if project members are unable to communicate effectively, the entire process completely deteriorates. This is, of course, not the problem of the design of the concept but rather a problem with the people trying to take advantage of the process. At times, it seemed like a big hassle to create an issue just to work on something but, again, this problem arises only due to a lack of consistent group meetings.
The command-line interface our group has implemented is fully functional and includes four commands for the users to interact with the WattDepot data energy at the Hale Aloha towers on the UH campus. Our design allows for the project's main execution to only create a processor, which then essentially takes over. In retrospect, having the main method exist outside of the processor is probably unnecessary, but in the spirit of keeping things modular, this was the design choice we made. The processor then explicitly "gathers" commands in a HashMap. Although I say "gathers" here, our implementation actually requires that we hard-code the existence of these commands into the processor. However, barring adding a couple of lines to the class, the system is modular and adaptable to accept additional commands.
Although I feel like the overall quality of the project is pretty good and is something I can reflect on and take some pride in, I am certain that, in the past 7 hours (6 of which I was asleep for), there was a significant amount of testing done to the completed project as a whole. Additionally, I found it really troublesome to write JUnit test cases for many of the classes I implemented, due to functionality conflicts like void methods or the infinite loop which drives the command-line interface. I was able to get fairly decent test coverage on the classes by making them more modular and testable but I am still very reluctant to say that the tests were "good". This perception does not, however, factor in ease of development for new developers, ease of use for users or even if the project can be successfully distributed because, again, despite having waited to the last minute, I ran out of time to fully test these requirements.
No comments:
Post a Comment