Tips from Students
Each offering of the class, we survey students asking what advice they'd give to other students. The top three on this list are stable; the rest of the list varies in ordering, but this ordering is representative.
Before coding something that is likely to be a feature used by other SaaS apps (file upload, capability management, and so on), take the time to search for Ruby gems or JavaScript libraries you can use or adapt. Even two hours of searching is less time than it takes to design, code and test it yourself.
Taking time to think about the key entity types (models), relationships among them, and how to capture those relationships in a schema using associations and foreign keys. A good design reduces the likelihood of a painful refactoring due to a schema change. (The instructors have found that Class--Responsibility--Collaborator cards, described in the book, can help with this process.)
Especially with the larger 6-person teams we use, a 5 or 10 minute daily standup meeting helped tremendously in keeping everyone on track, preventing conflicting or redundant work, and informally sharing knowledge among team members who ran into problems. Teams that met only once a week and supplemented it with online chat or social-networking groups wished they had met more often.
Teams that relied heavily on TDD found its greatest value in regression testing: regression bugs were spotted immediately and could be fixed quickly. Teams that didn't commit to TDD had problems with regression when adding features or refactoring. Teams that used TDD also noted that it helped them organize not only their code, but their thoughts on how it would be used ("the code you wish you had").
High coverage gave students confidence they weren't breaking things when they added new features; teams with low coverage found their project more brittle when others' changes were merged. High code quality keeps the codebase manageable: the fork-and-pull-request model is valuable in doing constant mini-reviews, and getting a high GPA from CodeClimate "felt great" as well as giving additional assurance.
Fine-grained commits and branch-per-feature were essential in preventing conflicts and keeping the main branch clean and deployment-ready.
Not everyone paired, but those who did found that it led to higher quality code and avoided silly mistakes that might have taken extra time to debug otherwise.
Teams in which one or a pair of developers owned a story had far fewer coordination problems and merge conflicts than teams that stratified by layer (front-end developer, back-end developer, JavaScript specialist, and so on) and also found that all team members understood the overall app structure better and were therefore more confident when making changes or adding features.
Lo-fi storyboards were really helpful in working with customer, and enable essential frequent customer feedback: most teams had at least one experience of building something they thought was cool only to realize the customer didn't care for it. Teams that made hi-fi prototypes invested a lot of time only to realize customer didn't like it. In general, a valuable lesson either way is the difficulty of transforming the customer's description into a technical plan---a key lesson of Agile that we wanted the students to learn.
"Containerizing" and structuring views using and other elements makes it easy to style them later without spending a lot of time up front to create the prototype. was very useful in quickly getting something presentable. In contrast, Rails scaffolding of views seemed like an appealing shortcut at first, but teams ended up rewriting almost all of those views anyway, suggesting that simple hand-created markup plus Bootstrap is a better path.
Last updated