This week marks the end of our month spent developing Campus Plate Mate, a website that reduces food waste by creating a space for students and the UH Mānoa community to share food items.
In this process, we used GitHub, a cloud-based platform used by software developers to code, share code, and collaborate on code. We used GitHub during the semester to store our coding workouts, however, this would mark our first (and final) ICS 314 collaborative project on GitHub. This was our chance to showcase the skills we developed throughout the semester.
We implemented a ticketing system: we assigned issue numbers for each development to branch off into and merge into our main branch. For example, update the footer to store feedback in a branch called issue-XX, where XX is replaced by whatever number comes next.
In addition to this system, we estimated our efforts on each ticket. The previous example I gave is something I did for our project. I had estimated that connecting the feedback we receive in our footer to our database might take an hour. However, it took longer than that–around 90 minutes. I noticed I tend to spend a lot of time when I code. I not only linked the feedback to our database, but I also updated the look of our footer to match the appearance of the rest of our site. I changed the font styles, button colors, and, well, other colors. It’s fun. Coding is pretty fun.
I would say my estimations were often not on the mark, sometimes they were slightly off, and sometimes they were way off. I think effort estimations may help with time boxing. Say, I estimated that an issue might take an hour. However, an hour and a half had already passed since I started, and I ran into a bug (an error within the code that I just can’t seem to fix!). This might encourage me to call it a night and try again tomorrow with a more sound and less tense mind.
Likewise, tracking the actual effort expended on the issues is not a bad thing to do. I mean, you’re already estimating how much time you’ll spend, might as well have something to compare it with. I liked that my team not only logged our actual coding effort and our non-coding effort because there is more to coding than simply typing out code. We also have to spend time researching, planning, and designing.
I do not think there are any downsides to estimating and tracking effort. It takes under five minutes to write your estimates, and then after completing a ticket to log how much time you spent. My tracking is accurate, too. Like I mentioned earlier, making an time estimation makes you that much more aware of how you spend your time. So, I did not have trouble keeping track of how much time I actually spent on a ticket. In addition, tracking my effort did not inhibit me from working on the project.
Anyway, I think effort estimation is useful, and I would consider doing some variation of effort estimation in future projects. Maybe we could have found out earlier how many licks it takes to reach the center of a Tootsie Pop if we did some effort estimation…