In my last post I started to talk about the importance of constant communication when working on a large team project. After working on teams of all sizes with members who had various levels of communication I can certainly say this is where most teams simply fail. Sadly the aspect of communication isn't that which will hurt the team the most when working on a project.
I've noticed time and time again with projects I've worked on that the process of creating a product is what is most neglected. It's a wonderful thing to see something just work, but when others are not able to replicate and learn from the process one could ask if the project even mattered. Some people would say "Of course this project mattered, I worked on X, Y, and Z. This entire project works, why wouldn't that be a success?"
This is where I find the issue with how we are taught to do projects in school. More often than not I will see teams work on an awesome project and once they have finished it just leaving it to sit on their portfolio. In some of the classes people are required to do postmortems to help them reflect on the process that went into the creation.
I personally don't think that postmortems make the cut for documenting the development process. They only provide a brief overview of one's thoughts after working on a project. Because of this they classicly neglect the different hopes and goals that evolved throughout the projects lifetime.
A possible alternative to relying on postmortems for the documentation process of development would be to encourage students to use issue trackers such as Trello, Jira, or GitHub. Having these issues tied in with commits also helps track the development process because we are able to tie in different sections of the codebase with different issues.