I experienced what it was like to take over a project that was already completed and add more to it. This project is the same software that I reviewed in my last post. For this project, we apply issue based project management.
In this project, we did not have much trouble with creating issues, rather the issues were minimal. We first focused on completing the new classes to be added to the software then decided on which issues were needed then. While we already perform testing side by side in development, we also created issues for further testing. In the end, we didn't spend too much time worrying about issues. Like before, I found the issues to cause me anxiety over whether or not something warrants an issue and if someone will take over it.
In this little enhancement, we added three classes, a class for monitoring if a tower meets their goal, it's helper class on setting a goal, and a power monitor. They all had their own challenges and I was assigned the helper class which is called "SetBaseline." I mixed my code with the already existing code for parsing input during the creation of my class to reduce development time. I've had to modify it to suit my needs. Using my own style helps greatly during testing since it differentiates itself from the other classes when it came time to integrating it with the main class. The challenge for this class was finding out how to store the baseline data throughout the software. I wasn't able to quite find out the solution to this problem myself and had to ask the other project members for assistance. Their solution was to create a static variable in the main class and import the main class into my class. From there, the baseline data can now be stored somewhere where it can be accessed anywhere. All it took was only two lines of code to enable this functionality. Quite frustrating.
The other two classes were monitor goal and monitor power and they had different approaches. Instead of being a one-time call, they were called and ran until the user decides to stop. To enable that, the Timer and TimerTask classes had to be implemented. I didn't have much to do with their development since we kept our work separate as project management requires to keep integration conflicts to a minimum.
Looking back on this, I've tangled with the Three Prime Directives on all levels, from the basic user to full-time developer. It helped me to see what condition the software was in and the quality of it and review its structure. Performing this enhancement has been an interesting experience for me. While I haven't tried out other management styles, I've been able to practice using issue-based management more. I've become more comfortable using Jenkins as a continuous integration tool, which came at a good time. Testing the software enhancements has become somewhat of a nightmare recently due to it constantly timing out when connected to the server, whereas on the Jenkins server, it tests fine.
This will be the last post I will make in a long time, possibly until I decide I want to blog again. It might be useful if I decide to start an extensive software project.
Wednesday, December 14, 2011
Thursday, December 8, 2011
Technical Review: A Continuation
Last time, I posted about continuous integration. This time, I will perform a technical review of another group's project. The project they are working on is a command line interface for a system known as Watt Depot. The Watt Depot system are servers located in the dorms of UH Manoa that monitor everyday use of electricity and is an ongoing project to reduce consumption of electricity. This group goes by the name of BackR, which means back row because they all sit there. The interface communicates with Watt Depot by getting information about power usage and displaying it for the user. More information about BackR's software can be found at this link.
This software was developed using two project management practices, including issue-based project management. The other practice used are continuous integration. To reiterate what issue-based project management is, this practice takes advantage of Google project's issue function to create issues on parts of the software to be worked on. Essentially, it is creating jobs to do. Continuous integration is the practice of reducing duplicate and conflicting work to a minimum. It uses a server software known as Jenkins which downloads the project from Google and uses Ant to verify that all there are no conflicts whenever a new build is uploaded.
I will be using the Three Prime Directives to review this project. These directives are:
Prime Directive #1: The system accomplishes a useful task.
Prime Directive #2: The system can successfully be installed and used by a new user.
Prime Directive #3: The system can successfully be understood and enhanced by a new developer.
Prime Directive # 1
The command line interface can accomplish a few tasks. At the moment, five commands are implemented: rank-towers, daily-energy, energy-since, current-power, and help. The rank-tower command ranks all the sources by how much power they consumed during a certain period of time. The towers are ranked from the least to the most consumed. daily-energy lists the power that source consumed on that day. energy-since tells you how much power was consumed from that day up to today. current-power tells you the current power consumption of that source. Finally the help command tells you all the available commands and how to use them.
I would say that it accomplishes a few useful tasks.
Prime Directive # 2
Downloading the program, it came with the source code and the jar file. The jar file was complete and didn't require any further action on my part to get it to work other than to execute it. It contains a version number.
This shows an example of this program in action.
It wasn't immediately known to me on how I would run such a program. Fortunately, there was a user guide available that I could read to find out. It lists the available commands but there wasn't an example of how they would be used. Installation seemed to be confusing as there was no link available to download Ant, a guide on how to install Ant, or whether it was necessary for a non-developer to use it. Executing the program itself was easy as there was an example of how to start it.
Below shows some invalid and valid inputs to test how the command line interface handles them:
current-power
daily-energy
energy-since
rank-towers
From this tests, it would be safe to say that it is easy for new users to install and use.
Prime Directive # 3
As a developer, I might want to add something to this myself if I find something lacking. It's an open source project after all and I should treat it as such. Looking at the developer guide, it tells me how I would begin development and which classes have been implemented. There is no way for me to find out what kind of standards the developers are using or if I'm going to meet them. The is a small note on what kind of management they use and that I should use it when I attempt something. There is no mention of whether or not it follows Continuous Integration.
Downloading the software from the SVN and generating Java documentation was a painless process. The information written were fairly short descriptions of each class. It supports information hiding by making all the global variables private and having accessor methods. I was able to build the system without any errors. Looking at the test source code, I can see that they have a large number of test cases for each class. Since each class has only one method for performing everything, it would be hard for a new developer to make modifications to these classes without breaking the test cases. The source code looked easy to understand since there were just enough comments that didn't make up more than the source code itself. Comparing the issues with the commits, it was clear who I could go to if I were to have any questions about the code. Although, it looked like one developer did the most work while the others did some. On their CI page, there was at least a daily development. Any issues they had were corrected promptly, usually on the same day.
A new developer would have a fairly difficult time modifying an existing class without breaking anything. Whereas creating a new module would be easy. It is easy to understand how the system works because the classes have been documented fairly well.
This software was developed using two project management practices, including issue-based project management. The other practice used are continuous integration. To reiterate what issue-based project management is, this practice takes advantage of Google project's issue function to create issues on parts of the software to be worked on. Essentially, it is creating jobs to do. Continuous integration is the practice of reducing duplicate and conflicting work to a minimum. It uses a server software known as Jenkins which downloads the project from Google and uses Ant to verify that all there are no conflicts whenever a new build is uploaded.
I will be using the Three Prime Directives to review this project. These directives are:
Prime Directive #1: The system accomplishes a useful task.
Prime Directive #2: The system can successfully be installed and used by a new user.
Prime Directive #3: The system can successfully be understood and enhanced by a new developer.
Prime Directive # 1
The command line interface can accomplish a few tasks. At the moment, five commands are implemented: rank-towers, daily-energy, energy-since, current-power, and help. The rank-tower command ranks all the sources by how much power they consumed during a certain period of time. The towers are ranked from the least to the most consumed. daily-energy lists the power that source consumed on that day. energy-since tells you how much power was consumed from that day up to today. current-power tells you the current power consumption of that source. Finally the help command tells you all the available commands and how to use them.
I would say that it accomplishes a few useful tasks.
Prime Directive # 2
Downloading the program, it came with the source code and the jar file. The jar file was complete and didn't require any further action on my part to get it to work other than to execute it. It contains a version number.
This shows an example of this program in action.
It wasn't immediately known to me on how I would run such a program. Fortunately, there was a user guide available that I could read to find out. It lists the available commands but there wasn't an example of how they would be used. Installation seemed to be confusing as there was no link available to download Ant, a guide on how to install Ant, or whether it was necessary for a non-developer to use it. Executing the program itself was easy as there was an example of how to start it.
Below shows some invalid and valid inputs to test how the command line interface handles them:
current-power
daily-energy
energy-since
rank-towers
From this tests, it would be safe to say that it is easy for new users to install and use.
Prime Directive # 3
As a developer, I might want to add something to this myself if I find something lacking. It's an open source project after all and I should treat it as such. Looking at the developer guide, it tells me how I would begin development and which classes have been implemented. There is no way for me to find out what kind of standards the developers are using or if I'm going to meet them. The is a small note on what kind of management they use and that I should use it when I attempt something. There is no mention of whether or not it follows Continuous Integration.
Downloading the software from the SVN and generating Java documentation was a painless process. The information written were fairly short descriptions of each class. It supports information hiding by making all the global variables private and having accessor methods. I was able to build the system without any errors. Looking at the test source code, I can see that they have a large number of test cases for each class. Since each class has only one method for performing everything, it would be hard for a new developer to make modifications to these classes without breaking the test cases. The source code looked easy to understand since there were just enough comments that didn't make up more than the source code itself. Comparing the issues with the commits, it was clear who I could go to if I were to have any questions about the code. Although, it looked like one developer did the most work while the others did some. On their CI page, there was at least a daily development. Any issues they had were corrected promptly, usually on the same day.
A new developer would have a fairly difficult time modifying an existing class without breaking anything. Whereas creating a new module would be easy. It is easy to understand how the system works because the classes have been documented fairly well.
Friday, December 2, 2011
Experimenting with Software Development Management
Group projects sound pretty simple in it's own context. Throw software engineering in and it becomes an entirely different animal. Unlike regular group projects where everyone does their own thing, software engineering uses a management concept known as "issue-based project management." This concept utilizes issues concerning the project which each member accepts to work on. Each group member works on nothing else but the issues they've accepted. The reasoning behind this is to reduce conflicts when integrating your work with another member's work effort. This sounds efficient in concept, but is it effective in practice?
I spent a few weeks practicing this management concept and I have things say about it. It seems cumbersome to work with considering that I have to created detailed issues to work on and then accept the same issues to work on.. Issues will definitely come up during testing which needs to be detailed and added to the list of issues needed to be looked at. Considering that there were only three of us working on this project, I can imagine that it causes less anxiety because there might not be any issues to work on when the project isn't finished. It would be less of an issue then.
By separating the work, I felt not so pressured when I could check up on what progress the others have made. Despite the fact that we created these issues, we haven't exactly discussed a standard way of solving these issues. It was fortunate that our project was designed to be modular, with only one point of entry for each module. We used an interface to standardize this point of entry then went ahead and did our own thing. Unfortunately, after the entry point, this non-standardized approach for our modules would make it harder for new developers if they were to look at our code since for each module, the modules we worked on were made with our own little quirks. One of the other group members had a completely different way of parsing a date compared to mines. When I created a date parser, it grew into a huge monstrosity that needed it's own class. I can't say that it was the same for theirs since it was contained within a single class.
I find issue-based project management to not be an effective management style to use when there are only three members working on a project. The amount of effort needed to find issues and consider whether or not it is worthy of it's own issue isn't worth it. Not to mention that Google Project hosting doesn't exactly make updating issue statuses convenient. Perhaps if we had someone who doesn't necessarily have to know how to program, but should at least know how to find issues for us to fix, this management style would have worked out better with less headaches.
Still, we were lucky enough to be not be grouped with any slackers and finished this project ahead of schedule, with the last few days spent just tweaking our modules and doing tests. We didn't miss any of the planned features. Our project is hosted here if you want to have a look.
I spent a few weeks practicing this management concept and I have things say about it. It seems cumbersome to work with considering that I have to created detailed issues to work on and then accept the same issues to work on.. Issues will definitely come up during testing which needs to be detailed and added to the list of issues needed to be looked at. Considering that there were only three of us working on this project, I can imagine that it causes less anxiety because there might not be any issues to work on when the project isn't finished. It would be less of an issue then.
By separating the work, I felt not so pressured when I could check up on what progress the others have made. Despite the fact that we created these issues, we haven't exactly discussed a standard way of solving these issues. It was fortunate that our project was designed to be modular, with only one point of entry for each module. We used an interface to standardize this point of entry then went ahead and did our own thing. Unfortunately, after the entry point, this non-standardized approach for our modules would make it harder for new developers if they were to look at our code since for each module, the modules we worked on were made with our own little quirks. One of the other group members had a completely different way of parsing a date compared to mines. When I created a date parser, it grew into a huge monstrosity that needed it's own class. I can't say that it was the same for theirs since it was contained within a single class.
I find issue-based project management to not be an effective management style to use when there are only three members working on a project. The amount of effort needed to find issues and consider whether or not it is worthy of it's own issue isn't worth it. Not to mention that Google Project hosting doesn't exactly make updating issue statuses convenient. Perhaps if we had someone who doesn't necessarily have to know how to program, but should at least know how to find issues for us to fix, this management style would have worked out better with less headaches.
Still, we were lucky enough to be not be grouped with any slackers and finished this project ahead of schedule, with the last few days spent just tweaking our modules and doing tests. We didn't miss any of the planned features. Our project is hosted here if you want to have a look.
Subscribe to:
Comments (Atom)