In ICS 314, students are required to develop a website as their final project and apply everything they have learned throughout the course. In addition to that, we had an optional task of tracking the time and effort we put into the project. The following is a reflection on tracking our effort and the estimation process we used for our final project:
In order to track our effort and the time dedicated to different parts of our project, we were first tasked with estimating how much time an issue would take. Initially, I estimated this by assessing my familiarity with the topic at hand. For example, I thought an issue where I had to update the config files and metadata would take 10 minutes at most, since we had done it many times during our WODs. However, I forgot where the actual files were located, and it ended up taking about 15 minutes longer than expected. From that experience, I realized it’s better to overestimate than underestimate, no matter how small the task may seem. After that, I started basing my estimates on similar tasks my group members had and my own judgment, often doubling the estimated time.
Although the estimates were often inaccurate, making them in advance still had significant benefits. It gave us a general idea of how long a task might take. Setting expectations for each task helped not only me but also the rest of the group, as it made it easier to divide up work more efficiently. For instance, if one person already had several hours of work, they could pass a new task to someone with a lighter workload.
There were definite benefits to tracking the actual effort spent on each issue. It helped us understand how knowledgeable we were about a given task. In rare cases where we underestimated the time, it indicated that we were well-prepared and understood the issue thoroughly. On the other hand, overestimating didn’t necessarily mean we didn’t understand the topic—it depended on how much we exceeded the estimate. If the actual time was close to the estimate, it meant we had a solid grasp of the task. However, if we went significantly over time, it usually meant we were unsure and needed to consult outside resources like ChatGPT for assistance.
Tracking the actual time spent coding was done through WakaTime, a service with a VSCode extension that logs how long we work on specific files. For non-coding efforts, I relied on my best guess. I did use a timer once in parallel with WakaTime to compare the difference and use that to estimate non-coding time. However, I only used it once because some issues took several hours to complete, and the breaks I took made it inconvenient to constantly start and stop the timer.
Tracking my effort took little to no time and did not interfere with the work I contributed to my group’s project. This was mainly thanks to services like WakaTime, which automatically track my coding time. For non-coding effort, I usually made a reasonable estimate based on memory and experience.