Doing More Cool Things with WattDepot

Alright, since it’s probably taken all the way from the last time until now to finish reading straight through the last post (the technical review of TNT’s Hale Aloha Command Line Interface), I suppose it’s time to tell you about the next steps my team and I have taken with this project. Keeping the original code base, we implemented further functionality on the product, to see if it could be done and with what effort and challenges. Our goal was to add three basic functions: set-baseline, monitor-power, and monitor-goal. Monitor-power outputs the current power readings of a tower or lounge every user-defined number of seconds until a character is entered, which terminates the task. Monitor-goal takes a baseline (defined by set-baseline) as well as a user-defined percentage reduction goal and calculates whether or not the tower or lounge is meeting that goal or not, and like monitor-power, outputs this every so many seconds as defined by the user.

Although there were some issues with implementing this such as getting the timer to work, especially with terminating on any character being pressed, majority of the issues arose from the fact that the bulk of the code— and it being the base, too— was built by other developers. Fortunately for us, the code base was built very well, with many advanced and well-implemented techniques; much more robust and easy to use (in the long run) than our own one was built. However, because some of the implementations went over our heads, it was difficult to understand it and get used to it in the beginning. But I don’t think that this was due to a lack of keeping with Prime Directive number 3 (an external develop being able to understand and install the system), because it was not due to poor documentation or unreadable code, or anything similar to that. It just took a little bit of time to understand, which is probably just normal with taking over someone else’s code. As mentioned in my technical review of TNT's product, the Three Prime Directives of Software Engineering were met, because the product definitely accomplishes something useful, the documentation provides clear instructions to installing and using the system, and an external developer can easily (or at least relatively easily) develop and enhance the system.

As far as the Issue Driven Project Management went, just as it was with our own Hale Aloha Command Line Interface, everything was rather smooth-sailing and we didn’t run into any issues. Again, it was great in the beginning for portioning out the work load, but as we had to make modifications to our code, it became less of a required thing and a little more of a nuisance. This time it wasn’t as bad though, because the command interface and processors were all created already, so we only had to implement the functions (and their associated test classes) themselves.

Most of our enhancements to TNT’s Hale Aloha CLI work well, and I’m actually quite surprised at what we were able to accomplish, given the little amount of time we had to spend on it, and the complexity of the tasks. One thing that doesn’t quite work properly is the functioning of the timers implemented in monitor-power and monitor-goal. It took a while just to get the timer properly implemented, and we could not get the termination of the loop to end properly. We would have liked for it to end when the user types in any character, but instead it only does so upon entering a carriage return. Another defect in the system is the full checking of whether a baseline was set before the monitor-goal command is run. The current setup has it where the baseline is not tower-specific. If set-baseline is run only for Ilima, for example, the user could run monitor-goal on Lehua, and not encounter any errors. This is a minor error and could probably be fixed rather easily, had we had more time. Other than this, everything seems to be working well, and I’m very pleased at the quality of the enhancements that we were able to produce in just a couple of weeks. The test cases prove that our system is pretty robust (other than the aforementioned flaw), and it is fully documented and working.


Working with someone else's code base-- or anything for that matter-- is difficult and can be a headache-- especially in the beginning when everything is so foreign-- but this process is beneficial in many ways. The obvious one is that it provides you with examples-- good and/or bad-- of implementation techniques, and so you can learn new tricks if there are any, and fix the places that are substandard. Secondly, however, being put in an environment where you are not only requires you to work as a team but to also switch products to compare or improve them forces you to write better code. Especially when you know that others' eyes are going to be looking at the code you wrote, you want it to be clean, correct, and the best it can possibly be. This includes documentation and code formatting, which are things that are often left attention-deprived when you know that only one set of eyes will be looking at the code. Plus, there's the pride aspect of providing really good code-- perhaps implementing a cool trick that you learned that makes a certain function simple, correct, and efficient; you can show it off in a "look at what I know how to do" kind of way, and that makes things a bit more fun, rather than "it's messy, but... ah, it works so it's good enough for me." Friendly, harmless "competition"-- if I may even call it that-- never hurts anyone, and is one way to intrinsically encourage good code in a pain-free way!