During winter quarter of 2021, I took CSE 110: Software Engineering. This course was, according to its description:

Introduction to software development and engineering methods, including specification, design, implementation, testing, and process. An emphasis on team development, agile methods, and use of tools such as IDE’s, version control, and test harnesses.

When I took the course, I expected it to be like any other CS course, lecture on topics, weekly programming assignments, a midterm, and a final. However, once the course started, I was pleasantly surprised. Instead of tests, the course was mostly project based (though we still did have weekly programming assignments). I was to be grouped with 7 others, and as a team our task was to create and implement a pomodoro timer, going through all the steps of proper software engineering while doing so.

Part 1: What is a Pomodoro Timer?

“What is a pomodoro timer?”. This question (or a variant of it) was asked plenty of times in the first few weeks, by the professor, by classmates, by me. A simple Wikipedia search will tell you that the pomodoro technique is a productivity method of splitting up time into “pomodoros” with the basic layout looking like this:

  • decide on a task to complete
  • for 25-30 minutes work only on the decided task
  • take a short 5-10 minute break
  • if there less than 4 pomodoros filled, fill one, go back to step 1
  • otherwise, clear the pomodoros, and take a 20-30 minute long break
  • once the task is done, record its completion

Though this may seem simple, there was actually a lot for us to consider: How long should each work section be? What about the breaks? Should 4 pomodoros be required before a long break? All of these questions were just about the basic purpose of our website! There were plenty of other decisions we had to make, such as the general tone of the site, what features we wanted to include, and who we wanted to caper to. Knowing that we had a lot to think about our group set up a brainstorming session. For this, we used Miro. In this meeting we ended up making a lot of the design decisions for the website. We did so by examining other, existing pomodoro websites and debating amongst ourselves. Eventually we came to the conclusion that the website was to simple and minimal, displaying what is only necessary. We had a rough idea of what we were going to do, and reckoned we could figure out the rest as we went along. After all, that’s what agile development was about. Miro Board The Miro board after brainstorming

Part 2: Work Work Work

Another major decision we made during the initial brainstorm meeting was how to structure our team. We had two leaders, while the rest of us were split into two teams, the design team, which I was in, and the development team. This ended up working quite well, since we were able to parallelize our work, design worked on creating and describing the look and feel of the website, while development began setting up the back-end development pipeline and implementing the basic timer functionality. The leaders organized team meetings, delegated tasks, and also reported our progress to the TA who supervised us. Over the course of the next few weeks I worked with the other design team members on the tasks we had to do:

  • Wireframes
  • User Flow Diagrams
  • Architectural Design Records

We worked on all of these together, through iteration and collaboration. For the wireframes, we first started with hand-drawn sketches, posting and soliciting critique on Slack, before settling on a general shape and feel of what we wanted. We ended up with a circular, fruit themed timer in the middle, 4 dots below to display completed pomodoros, and a single button to start and skip steps if needed. Then, we used Figma, a collaborative whiteboard tool, to create more polished versions of the wireframes. We worked on these for a couple of weeks, refining and polishing them up. Fruit Themes The final Figma board, off-screen are more versions/drafts, and the dark mode design

The other tasks, user flow diagrams and architectural design records were also created in a similar manner; we would came up with rough drafts, then built upon them piece by piece, working with each other the whole way through. Throughout this whole process we not only worked with each other but also with other members of the broader team. Every week, we had all hands meetings, where the sub-teams would share what they had done, what struggles they had, what feedback they needed, and what they planned to do next. Eventually, we were able to combine our designs with the development teams work, and the two sub-teams worked together to build the front-end of the website. By the time that was finished, it was nearing the due date of the project, so we wrapped up all we had done. We presented the website to the professors and class, and were proud of what we accomplished. We received a 100% on our website.

Part 3: Retrospective

Throughout the above writing, I’ve used the phrase “we” a lot, because it emphasizes what I feel was the most important part of project: the collaboration with others. The lectures in CSE 110 repeatedly emphasized the importance of good constant communication, and I feel that our team did great at that. The weekly all hands meetings, occasional sub-team meetings, and constant messaging over Slack, allowed every team member to ask for help, share their ideas, and generally contribute whenever they felt necessary. The process wasn’t perfect, we definitely had issues with organization and task management at the start, but over time, through communication, we were able to figure things out.