Give Me Your Knowledge: Capstone Design

This is not actually a blog post but a summary of knowledge that was shared about the Software Engineering Fourth Year Design Project during the Winter 2014 term. As always this is subjective and could be different depending on circumstances.

FYDP Sessions

Returning Projects

  • UWFlow - uwflow.com
  • The Notist - notist.co

What They wish they knew

  • Make sure your entire group isn’t taking trains, graphics, etc. all at the same time.
  • Don’t work with your significant other. Group breakups are bad…
  • Start generating ideas early on, even before starting on design project.
    • Keep a daily journal of ideas that come to mind and then discuss them with others
  • Keep a goal in mind for symposium (e.g. have lots of users) and work backwards from there
  • If your application requires users launch early
  • Don’t necessarily choose long-term technologies, it can be important to launch soon.
  • Start early and launch early. It allows you to write higher quality code in the long run.
  • If you are doing a research project, make sure it has good engineering. Good infrastructure, testing, build systems, etc. It can pay off in the long run (figuratively and literally).
    • Top two teams in 2014 had amazing infrastructure
    • Build/Test infrastructure pushed Amalgam over the top
    • The sponser loves this (=> $$$)
  • Research code is awful. Make sure your code is actually good. Crappy code is really bad…
    • Apparently, Rayside’s code is not the WORST, but still bad
  • Customer Definitions:
    • Research -> Professor
    • Open Source -> Maintainers
    • Corporate -> Actually Client
    • Entrepreneurial -> More of a technical mentor
    • Language will be clarified in 3B
  • Be pro-active about ideas, team, ideas.
  • Schedule frequent meetings (Mixbox did 3 times a week). Used to work on the project
  • Having one strong voice in the project to make defining decisions (Team Lead, Vocal People, etc.). Gives motivation and guidance
  • If you get a lot of work done in the school terms, you most likely won’t get it done over the workterm
    • Hard to arrange meetings, communication, etc.
  • Need good tools to figure what everyone is doing.
    • Pivotal Tracker for task planning (iterations)
    • Hipchat for communication
    • Github for Pull Requests + Code Reviews
    • Helps for asynchronous communication
  • Having a group member going on exchange can have a lot of difficulty
    • Weird meeting times because of time zones, exam times, etc.
    • You don’t see them every day
    • Workload won’t be balanced while on exchange
  • Inter-disciplinary groups can have some unique quirks
    • Hard to schedule
    • But can give a different perspective
  • 80/90% of work will be done together

Q&A

Q: Is there a good strategy for mitigating the co-op fall off (maintaining momentum during co-op)?

A1: Teams can potentially live together during a co-op term (may drive you insane). Be careful of doing this… REALLY CAREFUL!

A2: Chris & Ming-Ho lived together and didn’t murder each other. Results may vary. Still tried to schedule regular meetings (cross-time-zone). Built the entire infrastucture during the co-op term. However, it was not completely steady throughout the work term. tldr; Meetings and if they didn’t do it would be bad.

A3: Research and actively still looking at projects etc. can help a lot during the term. Examples are testing, different libraries to speed up development. Play with “competitors” if you have them - could learn things.

A4: It may not be possible to work on it during a work term. Amazon, Google (Interns) and IBM are really bad at this. Keep this in mind.

A5: Set deadlines for yourself (not necessarily meaningful).

Q: What are measures of success for a FYDP?

A: Measured in technical content, results and communication. Less of a undergraduate marking scheme. Pick a project that someone will care about after your graudate and do a good job. Demonstrate how people care about your project. Project specific basis for success (going add examples). UWFlow is the low bar for doing a CRUD (Create, Read, Update, Delete) project that everyone has tried before (did YCominbator pitch). We’ll get a list of projects that have done well as examples.

Q: How does a measure of success change if it is a taken over project?

A: Choose a project that as an extension is as ambitious as the original project.

Q: When do you know when you want to work on something?

A1: A lot of ideas will be pitched to us from various locations. Don’t worry too much about thinking of an amazing idea.

A2: Massive brainstorming sessions with people you want to work with can be useful.

A3: Can be a challenge to rally people around your idea, it may not be interesting to anyone but yourself. Think about what sorts of things you have in common with your classmates to direct ideas.

A4: This process will tried to be facilitated in 3B (SE 390). Keep all the other ideas for a potential SE499 (Independent project) if it doesn’t work out for FYDP.

A5: When deciding whether to organize an idea or a team, Mack says to organize around a team rather than an idea. Can usually find some interest. However, Rayside says to remain open-minded.