@Imogen_Kutz’s ‘A week in the life of an IATI developer’ describes the @IATI-techteam’s work on the forthcoming IATI python library – now known as pyIATI – and how it relates to other tools that the @IATI-techteam maintain. It’s great to have insights into the work of the technical team and sharing an overview of how different tasks are prioritised is much appreciated.
The blog describes the team following a number of software development best practices, some of which hint at an Agile approach. But none of them are explicit about delivering software early and often (i.e. iterative development), or customer collaboration (i.e. feedback from users).
I’m pleased to know that the PyIATI library is open source. And I understand that the tech team need to spend time building solid foundations. But I’m concerned about working for A Long Time on something without demonstrable output. As the UK Government Digital Service says: “Show The Thing!” Delivering early and often mitigates risk – and in this case, this risk is felt by the whole IATI community.
With finite resources, work on this library comes at the expense of work on other IATI tools and services such as the IATI Datastore, the query builder, d-portal, the IATI registry etc. Many of us here attended sessions on IATI tools at TAG, and suggested features and improvements. Having contributed to a number of IATI codebases, I have some familiarity with how they work. But I’m not really sure I understand how pyIATI will help address major issues with these existing tools.
I’ve made these points elsewhere, and @markbrough has made similar points here. But I thought it worth reiterating. I appreciate the answer will probably be “have patience” (indeed, I’m not sure there’s another response at this point) but I hope that in the future we’ll be able to avoid long periods where there are no discernable improvements to IATI tools for end users.