Previously, on "Trials and Tribulations" - Command-line interface hale-aloha-cli-hash was tapped for inspection (episode recap). Critics (me) of Team hash's command-line phenom raved about the tool, saying that it "does indeed accomplish a useful task" and that the team "did an admirable job". But the tool was not only met with gold stars and sunshine as the very same critics (still me) mercilessly pointed out that the application was "not without its flaws".
This episode is brought to you with no further commercial interruption by yours truly.
Strangely enough, although we still refer to Team hash as the trio of developers who were responsible for the genesis of hale-aloha-cli-hash, a twist of fate intervened and alas, the project that I had extensively reviewed previously suddenly landed within my domain of responsibility. Due to the nature of the Hale-Aloha-CLI project, the rationale behind Team chair suddenly taking over the hash project was sound. Often, a piece of software is written with a certain approach, design and frame of mind. These concepts, however, often belong exclusively to the originators of the software. In open-source development, it is important to keep new developers in mind, and since the objective behind the Hale-Aloha-CLI project was to create a user interface which was modular enough for new developers to add additional commands, it made good sense for our two teams to switch our development focus to each others' projects.
Although I had performed a fairly in depth review of hale-aloha-cli-hash in my previous entry, it became obvious that a hands-on experience was going to reveal so much more as soon as I began to start implementing a new command. Before I go any further, here is the project page for hale-aloha-cli-hash and you'll note that the system now accepts 3 new commands: set-baseline, monitor-power and monitor-goal.
All in all, the design of the system was pretty intuitive, all the code for execution of commands were together and all the code for argument checking were found together and so forth. The biggest challenge, initially, was fully understanding the thought process of the previous developers. There was a Java interface in the project, which I initially heralded as being uniquely dissimilar to the hale-aloha-cli-chair implementation. Unfortunately, upon further investigation, I found that the developers may have misinterpreted the reasoning for the interface to exist in the first place.
For some of you out there, it may behoove you to know that an interface acts sort of like a blueprint. It lays out the basic frameworks for building something, in this case a Command. After adhering to the basic frameworks, it then becomes the developer's prerogative to embellish and add functionality to the Command to make it unique and useful, as long as the basic framework remains the same. Interfaces, in terms of Java, define methods that have to exist for every class which implements it. However, in hale-aloha-cli-hash, the interface defines every version of existing commands and the only class which implements the interface is responsible for executing the different commands. What this means is that the interface becomes a blueprint that is used only once which, in this case, defeats the purpose of drawing one out in the first place. Secondly, due to this fact, every time a new command is added to the interface, it has to also be added to the execution class. It quickly became a little unwieldy to keep track of all the changes that had to be made to existing code in order to add a single command.
However, the real challenge was again in working with group members. It is certainly understandable that most members, if not all of us, had other big responsibilities looming on the horizon but it wasn't until the project deadline was starting to peak over the mountains to cast its oppressing rays upon the group that our lines of communication really fired up. I tried to pick up one of the more unique commands: monitor-power as my primary issue for version 2.0 of hale-aloha-cli-hash because it involved a bit of thread use (which I was interested in) and it served as a takeoff point for the monitor-goal command. What I found out soon after, however, was that monitor-goal was even more so dependent on the existence, or at least an abstract conceptual mock-up of the set-baseline command. Due to the division of labor that we had settled on as a group, this meant that if one command was delayed, it had the potential to delay another command from being made as well.
This was especially evident as the set-baseline command was not fully incorporated into the system until recently, and thus the monitor-goal command had be stalled in its production a bit. In the umpteenth hour, however, my team and I were able to roll out a working product. Given the fact that we were building our system on top of a previous developer's system, I thought that we did a tremendous job overall of adapting our mindsets to accommodate for the different design. One of the few downsides to this, I found, was that I caught myself essentially assimilating the style of the previous group, and was digressing from my own coding style. This is not necessarily a bad thing, but being a chameleon when dealing with poorly written code can prove to be a problem in the future.
I do not mean to boast here but to simply make an observation based on the facts as I perceive them. The previous developers of hale-aloha-cli-hash created a system that did satisfy the three Prime Directives of software engineering, but I strongly believe that hale-aloha-cli-chair's design was more intuitive for developers. Of course, this is not to say that hale-aloha-cli-hash no longer meets the third Prime Directive, but that we may have taken the third directive more to heart in our inception of hale-aloha-cli-chair. If nothing else, this should be a learning experience for everyone in that while it is important to have a functional product, you can never spend enough time mulling over and designing the architecture of your system from the ground up.
In the end, I am still a huge fan of Issue Driven Project Management because I believe that under the right circumstances, it can complement and expedite the development process tremendously. Despite some of the communication issues and some last ditch efforts to get things working, IDPM still did help our collaborative efforts along as a group in the end. The experience of taking over hale-aloha-cli-hash was one of the most unique experiences in my software engineering career and it was invaluable in the lessons it taught me and although the project is not without its bugs and flaws (some existing from the previous development team, while many others were introduced by our current team), I feel pretty good about the project experience overall and I look forward to a fruitful future of similar challenges!
As a final cautionary note, this may be the season finale of "Trials and Tribulations" but rest assured that I am fighting for the networks to renew it for many more to come!
No comments:
Post a Comment