DueDates on HackyStat

Premise:
After the release of our DueDates v1.1 project, we've been sitting back while waiting to see how our implementation is being tested and used. So far we haven't had any responses (weren't expecting them), but we will be graded for it as a class project. The purpose of this week's blog entry is to detail my experiences working up to using a software auditing system started by a professor and a group of alumni, called HackyStat. I took the time this week to explore its features and understand its impact in continuous development. HackyStat is truly optimized to help you and your team members better the "health" and quality of your product.

Setup:
Setting up the "ICU" program called HackyStat wasn't such a difficult task. I could understand that it might be more of a challenge for newcomers getting used to using quality assurance tools, but at this point we've surpassed those tasks. Most of my efforts were directed towards getting to know what each of the product's dependencies did. I was also more interested in knowing how it was put together. Yet this blog entry is about my experience using the product, so I won't digress any further from the topic. For long time Eclipse users, Hackystat provides a workable plugin suited to cope with settings in Eclipse. This neat looking .jar file (provided from the project's home page) contains the necessary module to easily install HackStat onto your local machine. Once you install the plugin on Eclipse, navigate over to the server hosting HackyStat. Once you are there, register as a member, verify your email and eventually log in to host your project. HackyStat project browser is the home for all the projects you may have hosted on the live server. You may take advantage of the numerous tools used to assess your project's health, and assists in understanding your project's level of efficiency or defficiency. In many ways it could show the path or direction your team is heading. This notion of knowing what your project looks like underneath a microscope has made me more cautious (but not too cautious) to the details of my enviroment. Of course, this tool does a good job at pin pointing the areas your project lacks and what areas it is excelling at, but it still needs that extra human element to interpret the data coming back. After getting through installing all sensor on your machine and successfully building and sending data to the HackyStat sensor server, what's left for you to do? It is up to your team members to address those issues to better the weak links or connecting factors relating to your project's health.

Experience:
I have yet to explore all the neat features of HackyStat, but in my short experience, I could see the potential of the product. In some ways, HackyStat seems to have this ghostly feel to it. I sometimes feel like I'm being watched, well of course I am, but it creeps me out more knowing that these sensors are constantly doing updates about my progress and assessing my activities. This may be intrusive and a violation of my privacy, but if its intensions are to assess the project as a whole, then my contribution as a programmer and team member of this project is necessary. HackyStat as a whole is a good project assessment tool, used primarily as an "ICU" monitor for your hosted projects. However, HackyStat doesn't assess the matters of the team members individually. As a whole the team members make up the team, but areas that are beyond the reach of HackyStat's sensors are not accounted for. I'm prone to say that these factors can and will inhibit dangers and warnings to the health of your project. You should use HackyStat as an indicator to pick out these flaws and to fix them within the confines of your project group.