In software development, it is easy to underestimate how much time a task will actually take. Features that seem simple at first often involve more work once testing, styling, and integration are considered. While working on Mānoa RoomieMatch, a roommate matching web application built by a six-person team, I was responsible for many user-facing features such as profile pages, navigation updates, and interface cleanup.
Throughout the project, I estimated my effort in advance and tracked my actual time spent on both coding and non-coding work. Although my estimates were often inaccurate, the process helped me better understand where time is truly spent in a real software project.
I made effort estimates by looking at each GitHub issue and thinking through what the task would require from start to finish. For most tasks, I based my estimates on three main factors: how complex the feature seemed, whether I had worked on something similar before, and how many different parts of the application the change might affect.
For example, creating or updating profile-related UI components seemed straightforward at first, so I often estimated one to two hours. However, tasks like fixing layout consistency, adjusting styles across devices, or cleaning up navigation for different user roles ended up involving more steps than expected. Since this was an ongoing project with changing requirements, my estimates were usually best guesses rather than data-driven predictions.
Even though my estimates were frequently off, estimating ahead of time was still helpful. It forced me to slow down and think about the full scope of a task before starting. In several cases, this helped me realize that a feature involved more than just writing code, such as testing on different screen sizes or making sure changes did not break other pages.
For example, updating the profile overview page seemed like a small task, but it required spacing adjustments, widget layout changes, and consistency with the home page design. While the time estimate was low, estimating ahead made it clear that this was not a one-step change and helped me plan my work more carefully.
Tracking my actual effort was one of the most useful parts of the process. By comparing my estimates to the time I actually spent, I noticed that non-coding work took up much more time than I expected. Tasks like testing, fixing small UI bugs, adjusting colors, and checking accessibility added up quickly.
This became especially clear when working on navigation and profile pages. Small visual changes often led to additional fixes across multiple components. Seeing this pattern helped me understand why earlier estimates were consistently low and encouraged me to plan for more buffer time on similar tasks later in the project.
I tracked both coding and non-coding effort using a phone or desktop clock. I would start timing when I began working on a task and stop when I finished or took a break. While this method was simple, it required discipline to track time consistently.
I believe my tracking was reasonably accurate, but not perfect. Some short interruptions or quick fixes were likely missed. However, the data was still accurate enough to show general trends, especially the difference between estimated and actual effort.
If I were to do this again, I would change how I estimate non-coding work. I would specifically budget time for testing, styling, and debugging instead of grouping everything into one estimate. I would also slightly increase my initial estimates based on past experience, especially for UI-related tasks where small changes often lead to additional adjustments.
Rather than trying to predict the exact time a task will take, I would focus on making estimates that are more realistic and flexible.
I made significant use of GitHub Copilot as a support tool while estimating and tracking effort during this project. Copilot was primarily used to help me complete tasks effieciently and provide explanations, especially for UI-heavy features where the amount of work is easy to underestimate.
I used Copilot to break down tasks such as building profile pages, updating navigation layouts, and cleaning up user flows into smaller steps. Typical prompts included asking Copilot to complete a task with certain specifications including commenting thoroughly and asking me for clarifcation if needed.
I spent a noticeable amount of time on prompt engineering and review. This included rewriting prompts, reading Copilot’s suggestions, comparing them to the actual project structure, and deciding which parts were relevant. In many cases, Copilot helped identify non-obvious work like responsive design fixes, accessibility checks, or side effects on other pages, which improved my awareness of the full scope of a task.
However, Copilot did not produce final estimates or track time automatically. All estimates were manually created by me, and all effort tracking was done using my own timing methods. The final decisions about scope, effort, and implementation were always my own.
Estimating and tracking effort during this project showed me that software development involves much more than just writing code. While my estimates were often inaccurate, the process helped me better understand how time is spent on real projects and how to plan more effectively. By tracking actual effort and reflecting on the results, I gained insight that will help me make more realistic estimates in future software development work.
I used ChatGPT (OpenAI’s GPT-5 model) to support the writing of this essay. Specifically, AI helped me with:
The final essay reflects my own understanding and voice, but I acknowledge that AI tools supported me in brainstorming, drafting, and polishing my work.