Weeknotes: 28th October 2019
This week I built the full review checklist.
This week has been split into two major tasks: implementing the full review checklist and dealing with some upload/data errors.
The upload/data errors were discovered as part of our attempts to enable organisation-level access. Out of an abundance of caution we were watching the application in more detail and became aware of some issues.
It’s a shake when these things pop up because they distract your focus even when unrelated to the task at hand. On the plus side, these are actual problems with a line system that we’re going to fix properly. It’s just a challenge to bake that work with cadence.
Checklist data models
I wanted to talk a bit about the data model for review checklists, since it’s where I’ve spent a lot of time this week.
We’ve long had a “lodging checklist” in Complete the deputy report, which is the first stage of reviewing whether a report is appropriate. The new “full review checklist” is checked against a subset of reports, either where escalation has been advised or when chosen at random.
The lodging checklist is backed up by a database table with a column for every question (e.g. has_deputy_documented_spending), which makes it quite unwieldy. It’s also hard to add new questions, as the database, entity model, API etc. all need to be updated.
With the full review checklist I’ve taken a different approach: there’s a “decision” field, and some metadata (reviewer, submission date) and a “answers” field. The “answers” contain a JSON blob with all of the specific questions asked and what the response was.
The benefit of this is that all validation and data management happen on the client side; the API just checks the JSON is valid. Changes to questions will be much easier, and we could expand this out to other checklists in the future (I’d like to retcon the lodging checklist into this structure also).
Part of the reason this would is that the questions in the checklist and fairly ephemeral: other parts of the application and reporting care about the final decision, but they don’t care about answers to individual questions. That level of detail is only needed on the checklist itself.
It’s great to get a chance to re-review checklists in this way. If we can update the lodging checklist too, I think we’ll be in a great position to sensibly and dynamically manage this data. It would also be one less bit of business data which we’re having to define.
- Investigated and identified some CSV upload issues in our service
- Reviewed how all 12,000+ clients will be handled by organisations
- Implemented the new full review checklist
- Moved our integration tests into a separate container
- Removed a weird backdoor-y thing we set up for tests which isn’t used any more
- Sat on a couple of interview panels for developers