Time Working != TIme Expected
08 May 2025
“Work expands so as to fill the time available for its completion.” - C. Northcote Parkinson”
Often I would find myself beginning large projects with optimistic timelines, thinking “I can complete it in record time easily.” This underestimation was true during my experience studying for the CCST certification I mentioned in a previous post on this site, and is also apparent while I study for the Security+ certification. My overconfidence has continued to be my downfall in the last weeks of school where my group and I have to create a website to help the University of Hawaii at Manoa community. When estimating how much time a task would take to complete for the project, I grossly overestimated how fast I could work. For a simple task, such as updating an existing element like a sidebar, my estimate of 10 minutes would sometimes take upwards of 30 minutes.
Early Struggles
A major reason why some of my time expectations were miles below the actual time required was partly due to the fact that we were working off of a common project which added a lot of overhead time to see if changes made were correct. This was my first time using Github in this manner to collaborate with other people on a bigger project. In the beginning it would take a couple minutes just to get my bearings over what needed to be done to make branches, clone to my local computer, and manage changes to commit/push. Learning most of it for the first time definitely was a big time sink in what I was trying to do.
Later Efficiencies
Once I got the feel for how to utilize Github to work on my parts for the project, the amount of time wasted just trying to get started was minimized, but there was still a big discrepancy in my estimates versus the actual amount of time it took to complete a component. One main reason for these later differences is I oversimplified the problems in my head, making the issues seem much simpler than they actually were. Though the elements we were implementing were somewhat similar to assignments we had earlier in the semester, implementing them in practice with no guiding video was a MUCH harder task than expected. Working with a hosted database was a pain as most everything interacted with it in some way, but we all couldn’t connect to it from local machines unless going through the site itself and pushing to main, which was not ideal. We eventually figured we could use our local databases to test functionality of the components we were making and then commit to main after we were sure it worked.
Reflection
Though many of my effort estimates were off, I felt that making the estimates in the first place before trying to implement anything was beneficial to all of us. It laid out what needed to be completed and taking that time in the beginning to lay the foundation for each milestone got us thinking about what actually needed to be done for implementation in order to make accurate estimates. Tracking effort of actual work was actually not beneficial in making more accurate estimates as problems got more complex. I personally may have underdone my actual working hours as I felt my process for tracking hours was flawed in some ways where I used my best guess by looking at the clock before I started to work and taking another look after the end of a session. I may have not included some work sessions because I forgot about them, but actually trying to track the effort took little to no time away from the project.
All in all, I feel it was beneficial to create an estimate of how much time I think a task should take, but saw little gain in actually tracking it.