Code Monkey Not Thinking So Straight: WattDepot Cli

Last time on Kendyll’s Software Engineer Blog: Hudson integration proved to be useful, but for what?

This time: the mystery revealed, WattDepotCli makes its appearance as an assignment!

Rolling strong through all the coding we’ve done so far for our software engineering class it was apparently time to up the ante as they say. Not only were we presented with an entirely new (though still Java based) project to work on, but we are thrown into our first fray with partners. Together we had to come up with a Command Line Interface for what we know as WattDepot.

WattDepot, for us at this point is an online server access to collected data on electricity and carbon consumption and generation, useful for monitoring patterns in energy usage and impact on society and the environment (and potentially your wallet as well). Our job is to take this system of data and create a Command Line Interface (all text no Graphical User Interface) known as WattDepotCli (the project page which has our project branch, ehiku) to display data from this database located on the internet. With several resources on how to access this data available we were warmed up and raring to go, unknowing of the troubles ahead.

You see the issue when writing any software for the first time, especially if you have a partner for the first time is always the matter of how to approach your work. Charting out how things are done is one important part, and when doing it solo the matter tends to be more of the “throw my gloves on and see where this goes” style while when partnered you side more towards the idea of “how to balance out their strength and my own,” at least that’s how I approached it. We tried to divide the work out, and organize the system we were planning to use, the command line specification provided by our Professor Johnson (the specs viewable here) gave us an idea of what the commands we needed were but we weren’t sure what would be the most effective way to split them apart. “Do we split it up by first layer commands (list all together, than chart, and total together in big blobs under that)?” and, “Do we try to split it up by second level commands?“ we questioned each step of our decisions. Not certain which strategy would work best, we started out just going in one direction, only to find ourselves turning around soon after. What more with a whole class doing the same thing it wasn’t long before the emails arrived questioning our style and potential form while providing us with hints on how to do it correctly. Once again the direction we took changed, and our directions mapped out as it a little kid were trying to go through the kiddy menu map at a fast food restaurant but couldn’t decided which way to go.

I believe it took us three different attempts at working out our command structure before we finally hit one that was working. Thanks to the extension in class we had another day to get advice from Professor Johnson and change our approach once again. It was at this point when I realized the trouble was that we were spending so much time on the programming of the structure and command connections that we were hardly getting anything done. It felt like we were doing a lot but what was coming out was eventually just rewriting what we already had to another idea. Several days and attempts later we finally figured out a way that was going to work for us. We split the refactoring of code to our new choice to one person while the other locked down the methods they could. This method allowed us to continue working on actual things that would hold (maybe not 100% but more than our structures) without wasting too much time.

Along the way we weren’t just bothered by this constantly changing approach as we kept getting advice, but our own tools proved to be a wall to climb over. For several instance both me and my partner Kimberly Heu ran into what we could only consider glitches in the Eclipse system, moments where it thought we didn’t import statements that were there and wasn’t properly compiling our code. Add onto that the constant need to monitor our files (even files we weren’t done with yet) for Checkstyle, PMD, and Findbugs errors so that we knew our builds were relatively stable to upload to svn and get to the other person. The frustrating part of that is even knowing the things were improper we often tried to get them through the system just so that we could keep up to date with each other’s files, knowing that we’d be fixing that part later.

We were not the freest of people either, with the work being partner based, and classes being at their busiest we were lucky to SVN and Hudson to manage the dates of our work, or else we’d be in a swirl of confusion. The tool proved to be helpful when they were not hindering the speed of our communications with each other, something that is probably more apparently when more people are involved.

In the end Kimberly and I finished what we would believe to be a working basic model of our code. If I had to classify it unofficially I would consider it to be Beta 1 (that is to say we did test it some but it is far from I would call error proof). We were unable to create test cases before we ran into our own personal limits for the day and decided that getting what functionality we had together would be more important than making tests, especially knowing we’ll have time to rearrange and fix things in the future. To satisfy our own personal goals we got the commands to work under the examples provided (though not as the specifications intended all the time), and could see them work ourselves.

Overall for me, the project feels pretty rushed, and rather everyone rather unprepared. Something that concerned me the most was that almost everyone’s original approach seemed wrong, at least enough that Professor Johnson would address that to us. For us as students though we couldn’t do much more than what we were trying to do with what learning we’ve had before. I consider it a rather good feat that in a week we were able to learn a virtually new repertoire of commands, get them to work, and then make our own commands for them in an organized fashion with another person. One has to wonder where this will go given that this project isn’t over yet, but as I imply often in this blog, only time will tell.

Want to read another perspective? Feel free to hear how Kimberly handled our groupwork here.