We have talked about start of this project in a previous blog post.
aside: add a timeline.
- We started with building basic search and subject dashboard. We realized after building this that we should have used our models module because we need to pass those models to our rules system. This took the team some time getting used to.
- We started working on a spike to execute server side rules. We decided to keep the rule execution on the server side for performance reasons. At end of the spike we came up with an architecture where we use Node.js on server side to for rule execution.
- We started working on different form workflows like registration, enrolment, program encounter. But without the rules as we need to finish server side stories for rules.
- We started working on server side rule execution.
- Near beginning of the May, we realized that even though it's still going to take some more time for release of full fleged data entry app, we can still do a readonly app release. Readonly app release will enable the admins and supervisors to see data of all the subjects across all catchments from the web app.
We are ready with the release of Readonly app.
- On the full fleged app release we still have following things remaining:
- Integration of rules with webapp
- Encounter workflow
- Full fleged search with support for custom filters
- Access Control
- Location, Subject data types in forms
- Support for Groups and Household
- Growth Chart/Vaccination
- Attendance
- My Dashboard
- Acceptance Tests
- Working with people outside from your organisation is a different ball game. Also this project was distributed initially between Bangalore and Pune, and later became completely remote because of the Corona situation. We learned the following things from this engagement:
- We need to map the skill levels of team members before we start the project. If required, start with extensive training that makes the fundamentals of the used technologies very clear.
- We need to have a full time tech lead on the project from the start.
- All members of the team has to focus on developing full stack understanding. They don't have to be able to write the other stack code but they should be able to understand it from high level.
- Existing big JavaScript codebase can be hard to understand. We require more comments and documentation like Entity Relationship Diagrams. May be in future we can explore using TypeScript which makes it easier to understand big code bases by the virtue of having types.
- Code Reviews:
- Pull requests have to be small. It's very hard to review big pull requests well.