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!
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!
