As part of my university module on software engineering, we worked in a group of 6 randomly assigned students and had 12 weeks to design our own web application. I hope the following is helpful for the greater software engineering in understanding what it’s like to work on a project together.
Week 1 — Introductions : After the term break it was difficult getting back into the flow of working. However I was happy the rest of my group was so enthusiastic. We had to figure out what our app should be about.
Week 2 — The idea for what the application should be came to fruition. It was going to be a running app that plotted a route and created a playlist of music to listen to. At first this seemed too trivial because of the wide-availability of APIs, but as often occurs, it ended up being a technically challenging project.
Week 3 — The first few weeks were not actually spent on the project. I suppose the instructors wanted us to learn how to work together first before getting into the nitty-gritty. We learnt about WBS and network precedence diagrams.
Week 4 — We started on the project definition document now, and soon after created a pitch.
Week 5–6: We finished the project definition document and submitted it. We went through a peer review process, however this was evidently not enough as we barely scratched the surface of the mark bands. What’s funny is that a lot of us were hyped up to get the top mark band but I did not at the time think the marking would be so strict.
Week 7 — We start on the final audit report. This is where we write about the project in depth. I wanted to do a lot for this to make up for the disappointment of the PDD. I also did some coding for the application.
Week 8–12 — We finish and peer review the FAR and updated PDD, and launch the web app on Heroku. I have decided not to link it because if a lot of people click it a teammate will probably get charged a lot of money and because it’s still technically being marked so I have to be careful about what I put.
So what is the take away from this?
- APIs are powerful but unreliable: Since you are relying on a third-party, you can do a lot more than if you were by yourself, but you also have to respect the fact that the code is now no longer fully in your control. Think about this for data privacy reasons. During our project one API actually went offline forever! This was a setback but as a group we adapted.
- Working in a team is powerful, much more than working by yourself. Being able to have others to talk about the project with and to support each other is awesome. However, like a third-party API, it’s less reliable than doing work by yourself, unless you take the time to build camaraderie and trust in each other.
- I have a lot more respect for software engineering projects now. It takes a lot to be able to make a project on time and while working with other people, often not even in person. Project leads have a tough job dealing with the interpersonal problems, and I’m glad our team was relaxed about proceedings as it was good for the atmosphere.
- Project sponsors and project leaders have a lot of weight on their shoulders. It’s a fine line between dictating and bossiness and being too lax to lead. It’s also a good skill to learn to juggle such responsibilities.
I hope my experiences have taught you something about software engineering projects, even if it was a limited student experience.
