A week in the life of an IATI developer

Published by: Rohini Simbodyal on the Wednesday, August 30th, 2017 - Comments Off on A week in the life of an IATI developer

This post was written by developer Imogen Kutz working in the IATI technical team at Development Initiatives

Meet the Team

Working alongside Hayden (joined November 2016) and Dale (joined April 2015), I (Imogen) joined the team about 3 months ago. Together we manage the menagerie of IATI tech – a mix of codebases using varied languages and software design patterns. The increase in our development and maintenance capacity over the past year is thanks to IATI’s Members’ Assembly approving an uplift in budget, enabling us to bring new people into the team.

As a recent addition to the IATI Tech Team, I’ve been spending the last couple of months finding my feet. In the process, I thought it would be good to share some insights about how we work with the wider IATI community.

So here is a casual breakdown of our working week. Enjoy!

Monday

Monday is our dedicated bug and maintenance day. Of course, if a major emergency crops up we’ll get it sorted on any day of the week but most Monday projects are small irksome things rather than big hefty problems. We’ve earmarked one particular day for these projects because, as any software developer knows, maintenance is an ongoing process that needs specific time allocated.

This is especially true for IATI which suffers from a pretty complex code base. The code for our 10+ tools and services is written in at least six languages to a variety of coding practices. Fun times…

Delving into the IATI code base is a lot like a C.S. Lewis book. You lose a sock, check your wardrobe for it, and end up in Narnia. You spend many days wandering about, surprised at all the strange creatures you stumble across and, when you leave, hardly anything of any particular relevance will have changed.

This sort of problem is pretty ubiquitous when it comes to most code bases of a certain age. The typical circumstances are generally hard to avoid:

  • A series of pragmatic decisions where the need to prove the initial concept comes before there is a real need to think about scalability and long-term maintenance.
  • The need to respond quickly to early user needs leaves limited time for improving code.

These sorts of things leave us with software that is functional and demonstrates early user value but ultimately requires significant effort to keep working over the long term. A perpetual victim of what we in the business call ‘software rot’.

Allocating specific time for regular maintenance keeps us on top of high priority issues while allowing us to move forward without spending 15 years fighting for Aslan against the White Witch.

Tuesday-Thursday

These days are our main product development days. At the moment this is mostly taken up by creating IATI’s new python library pyIATI (pronounced pie-at-ee!).

pyIATI – a developers’ tool kit for IATI aims to consolidate duplicated efforts across the IATI code base, create a central point of reference for all our IATI tools, and reduce the maintenance cost of the code base. It’s basically magic.

Learning from lessons of the past and doing what we can to adhere to best practices means the processes we are using for pyIATI put quality, stability and longevity first.

This means:

  • Building features based on User Stories
  • Robust testing
  • Regular code reviews
  • Communication and knowledge sharing
  • Frequent refactoring (restructuring code to improve non-functional aspects)
  • Clear documentation added as we go
  • Research and evaluation of processes
  • Iterating over assumptions and design

All of this takes more time up front but will be a huge time-saver in the long run.

To switch to construction metaphors, think of it like carpentry. It may take longer initially to measure up your plank at least twice, but you’re saving a lot of time and money later when you only need to cut it once. The alternative being messing it up, running out of materials, and having to go back to the store to spend yet more time and money buying replacements.

Except, in our case, you’ll only need to fetch your data once, or convert to CSV once for example. Right now, those tasks are happening at least three times a piece which significantly increases maintenance effort when bugs crop up.

It’s also a question of foundations. The initial foundations of IATI were based on prototypes and so require significant effort to keep running. Things built on these foundations are fighting a losing battle and will eventually be swallowed up by encroaching entropy like a slowly sinking house. For example, we would like to add new features and improved functionality to the Dashboard and Datastore, but just keeping up with existing reported issues for these tools already takes up too many of our resources.

pyIATI is a big effort to underpin the foundations and shore everything up now, before we end up with serious subsidence problems later. In the case of IATI, pyIATI means it will be easier to extend existing tool functionality, create new shiny end-user tools, and fix problems with existing ones. We don’t want an unmanageable swamp of bugs swallowing up our ability to incorporate new user requirements.

Friday

The end of the week offers a chance to tidy up loose ends from our main product development days, as well as manage relationships with external suppliers, engage with the community, and reflect on our workflow to improve our own processes.

Upcoming

So that’s what our working week looks like right now. We’re on track to start using pyIATI for the project to build a new IATI website in the coming weeks. This will be a great way to test its real-world functionality and identify areas for improvement in order to streamline future projects. #TheJoysOfSoftware

Back to top