Mind reading up and down
Part 2 of a Series About Grant-Funded Academic Software Engineering
“If you wish to make an apple pie from scratch, you must first invent the universe” Carl Sagan, Cosmos
This post is part 2 of a series inspired by the presentation we gave to the ARDC Platforms Community of Practice. Future posts in this series will look at the other roles that academics need to play in order to deliver functioning software that other people want to use. Our prior post was from the perspective of the Product Owner. This post was written from the perspective of a Subject-Matter Expert who was also responsible for delivering data collection workflows to researchers (our ‘Client’) needing to use them in the field.
FAIMS Mobile1 did not do anything on its own. Client input was essential for customising the platform into a useful and usable module for fieldwork. Without a GUI, the client needed to work with a subject-matter expert in the FAIMS team to produce a tool that would succeed in his or her remote field deployment.
The subject-matter expert had multiple responsibilities that can be summed up as becoming the client on behalf of the client. These were 1) establishing a clear understanding of the necessary specifications of needs and fieldwork conditions, and assessing field risks, 2) communicating the client’s workflow to the product owner, and 3) testing the module prototypes for correspondence with the client specifications.
This process required constant mediation of both client requirements and technical “correctness”. When designing a module for an architectural survey, the developers thought it best to model the houses as walls containing windows and doors. The client, however, was content with houses being recorded as a single page called ‘building’ with walls and doors being listed, counted, and described in free-text fields. After burning the time with modelling it “right”, the project owner and domain-expert had to spend a Saturday devolving the module to the flat sheet that client had requested so that it would work in the field.
A different case was with auto-numbering of records. Clients naturally wanted to be able to find and retrieve records. They also wanted the identifiers to comply with 30 years of legacy identifier styles. While we were able to provide such magical auto-numbering systems, the clients were unwilling to wait for their anemic devices to calculate these in the field. Most such elaborate ID-schemes did not survive the first deployment and were brutally simplified. An example of project that needed brutal simplification is shown below.
The successes and failures of the first deployments taught us how to respect the needs of the clients and balance them with the capabilities of the software. We figured out how to compromise with clients’ expressed and tacit needs, and we also learnt how to work and live with the consequences of our software design decisions.
Other posts will explore these consequences further.
FAIMS Mobile v.0-2.6 was a platform for mobile data capture in the field, developed by archaeologists in 2012 and deployed at over 40 projects in the following 8 years.