Project FAQ

Are there any technologies we can’t use?

You are welcome (and encouraged) to use any of the technologies we have worked with in class (and libraries for those technologies, e.g. various React libraries). Outside of those technologies, please check in with the instructor(s).

Can we deploy to an alternate platforms?

Yes! The key requirement is that your project is deployed and publicly available (i.e., not just running in development mode on your personal computer). You are welcome to use any platform that meets those requirements. That said only the “official” approach described above will be actively supported.

How can I ensure my project is not successful? Project anti-patterns…

In past years we have observed a number of anti-patterns:

  • Large backlog items. The large scope leads to difficult merges. And large items are incompatible with pair programming. You will not have enough schedule overlap to complete work.
  • Long-lived branches. The projects move quickly and branches with partially completed features quickly get out of date. Don’t let a feature sit partially completed. Aim for backlog items that can be completed in a few days at most.
  • Tactical vs. strategic programming, i.e., prioritizing writing as much code as quickly as possible without consideration of the future. The resulting complexity often boxes teams in for the rest of the project.
  • Put off the server-side functionality. Don’t put off the server/database, implement a skeleton of your server and initial data models in sprint 1 to have template to guide subsequent development.
  • Don’t use your CRC cards to hash out your model representations.
  • Choosing an unfamiliar technology for no particular reason. This class and project is a great opportunity to learn new technologies, but those choices should be motivated by the needs of your application. If there isn’t a specific need then a technology that is unfamiliar to most or all of your team will likely be (and has historically been) a hindrance not a help.
  • Ignore the code your teammates are writing if it is not a feature you are working on.
  • Only test your production deployment at the last minute. You should be deploying regularly such that doing so is routine.

I encourage you to revisit the “Advice from CS169” slides sprinkled throughout our lectures. Those very relevant suggestions are sourced from undergraduate students in a similar class, implementing very similar projects.


© Laura Biester, Michael Linderman, and Christopher Andrews 2019-2024.