...
- The need for user testing became salient. There were various quirks about our system that were immediately apparent to usour test users, but which weren't quite as obvious to our test usersus, and we wouldn't have been able to catch this without user testing. Since we are all familiar with the mental model of our design, it's easy to overlook things that may be difficult to understand to outsiders.
- There is a lot of value in sketching out and designing the object models and relationships before beginning implementation. Some of the relationships between objects in our system aren't always that obvious and have some quirks. A lot of time and grief could have been avoided if we had sketched out in full detail all of the different models, their properties, and their relationships to each other, before beginning implementation. To provide some examples: Each person has a user account. Each user account has an associated family member profile, which belongs to a family. Event details belong to a family (so all members in the same family see the same calendar) but there can be multiple event details (including drivers and such) associated with each event (to permit sharing). None of this is necessarily particularly convoluted, but it would've made development much simpler for all parties had we hashed out these models and relationships beforehand.
- As is often the case with most projects, one starts off very ambitiously, and when it comes time to implement and meet deadlines, it becomes really obvious really fast that one won't be able to implement the feature set one desires and needs to scale down. It would have been good, from the start, to begin with a much simpler product with less features (yet still satisfying the core necessities) and scaled up from there if time permits. Having a few too many features left to our engineering efforts becoming spread too thin, with many features not being as polished as they could be. This may also be a consequence of simply the problem we chose to tackle, which would necessarily have required a diverse set of features. Thus, there may have been some value in being more critical at the early stages of which problem we wanted to tackle, and pick one that intuitively might not require a solution with a large amount of functionality.
- In terms of choosing which technologies we work with, though this shouldn't be central to the project, it has a large effect on the amount of time required to complete various tasks. General unfamiliarity with the various technologies used (Django/Postgres/HTML/CSS/etc...) meant that completing relatively simple tasks would take a fair bit of time since one would need to constantly consult the documentation. Not really something we could have done much about, since we picked technologies we were most familiar with, but it couldn't have hurt for our members to have had more experience in them to begin with.