Enhancing An Existing Project

In my last post, I did a technical review of an open source project to analyze how well it met the Three Prime Directives of Open Source Software. This week I have put that analysis to the test by actually enhancing the project. My group had created a system with the same functionality, but of course we approached the problems in very different ways than the group that created this code. Having written a similar system made some aspects of adding the enhancements easier because I knew what to expect, but it also made some parts more difficult because I made assumptions based on our previous project that weren't always true with this new project. Working with my group went really well this time, partially because it was a smaller job but also because we were familiar with each other's working and communication style.

My group added three new functions to the command-line interface. The first is named "set-baseline" and takes a location and a date as arguments. For the given location it gathers, prints, and stores the power usage for each hour throughout the given day.  The second new command is named "monitor-power." This command takes a location and optionally a time interval in seconds as arguments. It prints out the amount of power being used at the given location every few seconds, as determined by the interval. The default time interval is 10 seconds. This continues until the user presses the Enter key. Our third new command is named "monitor-goal" and combines the functionality of the previous two commands. A location, a power-reduction goal amount, and a time interval are given as arguments. The command compares current power usage to the baseline power amount stored by set-baseline for the given location at the current hour. It then checks to see if the baseline amount has been reduced by a certain percent, as determined by the goal argument. For instance, if the baseline for a location was 10 kW and the goal was 5, the current power usage would have to be reduced by at least 5% (9.5kW or lower) to meet the goal. Like monitor-power, this command continues to print at regular intervals until the user presses Enter. 

It should not be a surprise to any experienced developer to hear that adding code to the system was fairly easy, but adding code that was consistent and robust in regard to the rest of the system took much more effort. Completing the technical review last week helped with this task because I was more familiar with the project than I would have been. I probably wouldn't have taken the time to look through the resolved issues, which actually gave me a lot of insight into the history and decision-making that shaped the code.  One thing I wondered about was how much I should deviate from the existing structure of the code in order to improve it. For example, the project had test cases for all of its commands in the same class. I disagreed with this design decision (as I mentioned in the last post) but I wasn't sure if I should follow it. On one hand, separating my test cases will make my command easier to maintain. On the other hand, it may be confusing for the original developers or new developers to work with the code since they won't know where to find the test cases. Another approach would have been to separate all of the existing test cases out into their own classes, but I didn't want to spend too much time messing with code that already worked. I ended up putting my tests in their own separate class, but I am curious how this type of situation would be handled in a bigger project.