The Product Owner Must Translate Between the Academic Vision and the Developmental Reality
'Space is big. You just won’t believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to space.'
Douglas Adams, The Hitchhikers Guide to the Galaxy
This post is part 1 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.
Asking a workshop of academics is not enough to get a good idea of what developers need to do:
Thinking about the epigraph and the difficulties of academic research software development, we can replace the word 'space' with the word 'requirements' (and to the pedantic, the word big with the word difficult.) The task of requirement articulation is, itself, not well defined to most academic groups. Academic teams start with a (funded) vision of what they described in a grant request to get some money. They then need to articulate, test, and translate this vision to the research software engineers they have engaged1.
This vision needs to be translated into a self-consistent, possible, useful, and technically achievable set of requests to developers that really should take no longer than a week. Even assuming that the vision represents a product in detail that other folks want to use and support, this task of vision operationalisation is tricky. Trying to perform this task by committee is functionally impossible.
Here, we would like to introduce you to the idea of a product owner. (This advice is offered regardless of what software development life cycle theatre2 you have chosen. In short, the product owner is the single person on the academic side of things who will manage translation between the academic understanding-of-world-to-be and the pragmatic realities and tradeoffs of development. If they are not spending at least a day a week on this level of coordination, they do not have this job. The product owner needs to understand what the devs are working on, what they are planning to work on, and the day to day challenges that they are facing. The product owner needs to understand the ultimate vision, the pragmatic realities of funding, and what people are 'willing to pay for.'3
In another post in this series on academic roles within an academic software engineering project, we will talk about requirements elicitation, what everyone else on the academic team should be doing, and why features should not be priority number one.
As a warning here: if you have hired a single engineer for your grant-funded development, you have fallen into a classic blunder and should think about who is going to manage your testing, the day to day pragmatics of development, and what happens if your dev gets hit by a bus, wants a vacation, or moves to a better job.
Inspired by Bruce Schneier's 'Security Theatre' -- we are rather accepting the pragmatics that academics do not have participating in software development as their primary job. Committing to a software development lifecycle requires resources, time, consistent focus and seems to be the exception to our experience. In short, an SDLC, for academics, is a way of articulating what might happen in the best of all possible worlds until the money, time, and goodwill run out. Picking one that works with how your developers work is great, and having one is better than not -- but accept that much of what makes an SDLC valuable to software companies is merely performed without substance by us external folk.
Mistaking what people say they want for what they are willing to invest time and money into (even if it’s free) is another classic blunder.
For more news, subscribe!
