Postmortem

Reviewing our development experience:

After discussing some of the issues that arose during the development of your process. Included some of the neagtaive and positive point and what could have made this experience better.

Negative and Positive Points

What would you do differently if you had a chance to start over?

  • One of the key takeaways from this project was the importance of design patterns and code smells. Looking back, our team realized that we could have saved a significant amount of time if we had known about established design patterns and common code smells from the beginning. This would have allowed us to avoid the need for extensive code refactoring down the line. Additionally, our team realized that we could have chosen easier features to work on, which would have allowed us to focus on writing good code rather than rushing to complete features.

  • Another important lesson learned was the value of thinking outside the box. Our team realized that we had been too influenced by the apps we were familiar with, and had not taken the time to truly consider what would make our app unique. In hindsight, we should have spent more time brainstorming and exploring new ideas, in order to create an app that stood out from the rest.

What did you learn about team or large project development? What will you start doing, or stop doing next time?

  • When it came to the actual development process, our team learned the importance of clear communication channels, internal deadlines, and setting clear goals and expectations for each iteration. We also learned the value of collaboration, and working as a team towards a common goal. One area that we could have improved upon was conducting code reviews to identify potential issues and improve code readability. For example, there were times when the UI team and the logic team were out of sync because they had different ideas about the exact functionality a feature should implement. This could be prevented by conducting a joint code review.

  • Looking back, our team realized that we could have done a better job of sticking to a common coding style, and adding more comments to our code. In the future, a common coding style would make it easier for other team members to understand and work with different code. Additionally, we realized that it was important to avoid taking shortcuts that reduced code quality, just to make things work in the short term.

How did the project change for your initial (iteration 0) vision or stories or did it work out as predicted?

  • Reflecting on how our initial vision for the project had changed over time, our team realized that we had predicted more features than we were ultimately able to implement. For example, we wanted to have business accounts, reviews, filters, wish list, and a slew of other features that we did not have time to implement (due to time constraints and other obligations). However, because of the agile methodology and our trunk-based development process we were able to adjust our expectations and deliver a solid project regardless.

Can you draw any conclusions from what you’ve done?

  • In conclusion, starting a project from scratch is never easy, but with careful planning and attention to detail, it is possible to create a successful app. By learning from past mistakes and adopting best practices, developers can build apps that are easy to maintain, scalable, and user-friendly. Some of the key lessons learned from this project included the importance of design patterns and code smells, the value of clear communication and collaboration, and the need to think outside the box. By applying these lessons to future projects, developers can create apps that are both innovative and functional.

The Postmortem document can also be viewed on the GitLab Project Postmortem Document