Skip to main content

A Model Project


And this is how it goes. One thing to another ...

At the weekend I  was listening to Gene Kim's Idealcast interviews with Dr. Nicole Forsgren and Jez Humble. Jez Humble was talking about the importance of rapid feedback and referenced a Brett Victor talk that had stuck with him over the years:

... he built this little JavaScript game and he was changing parameters and the game was changing in real time. And his whole comment is like, if you can change something and see the change as you are changing it, it's incredibly powerful.  

And so I looked it up in the show notes and watched it. Wow ...

Inventing in Principle shows examples of experimental tooling for creative activities, particularly those that include a temporal dimension. The essential idea is to reduce the friction of having to maintain a model outside of the tool.

In the image at the top, the left side is a traditional IDE and the right side is a dynamic visualisation of the function being developed. You might imagine this is some kind of fancy trace left by a debugger. You'd be wrong. 

The view on the right updates as the code or inputs are edited ...

Without this, programmers model data flowing through the algorithm in their heads, perhaps augmented by a static surface such as paper or a whiteboard, sets of inputs and outputs, by printing or asserting at tactical locations, or stepping laboriously through the execution. 

Victor's approach doesn't remove the need for a model but it does make the item being created into an explorable example which means that its much easier to ask it questions, test it out under different conditions, and develop an intuition for it.

The term explorable example is new to me, but the approach is not. I use spreadsheets extensively to explore data and behaviour. But spreadsheets are another model, an abstraction on top of the system I am actually looking at.

And so I got to thinking about models ...

I recently joined an early stage project which is building a service to expose a new API but calls into an existing service for most of its functionality. The core personnel on the project  work together on the existing service. The API has been designed by our architecture group. I come from a third team.

As we began to explore the proposed API and its relationship to the existing service, it was interesting to observe the models that were created individually and collaboratively. They included:

  • A specification for the new service written as an OpenAPI document. Deliberately clean-roomed to avoid biasing towards implementation details of the existing service, it also looked forward to a more general service that might come later. This model aimed to subsume the functionality needed for the specific project but at the same time was incomplete around error handling and a particular subset of endpoints where stakeholder needs were still unknown.
  • A mapping between the endpoints and request payloads of the new and existing services in a simple table. This model sanity-checked that the data required for any supported transaction would be available, identified places that state might need to be preserved in the new service, and flagged similar concepts with different names and different concepts with the same name.
  • A Miro board describing user interactions with a client UI that would call the new API. This model was helpful because it reminded us that there was a human base to this project, and it had been built in collaboration with our stakeholders. It also showed multiple alternative paths through the client application and hence implicitly the API.
  • A sequence of request-response pair mock-ups between the new service and some client as JSON, in a Markdown file. This model was particularly valuable for those familiar with the existing service because, in their heads, they could already align it with the new service. It also meant that we could model an end-to-end workflow very quickly.
  • Another Miro board model which also modelled the end-to-end journey but abstracted away almost all detail to focus on just two data types. This was helpful because those types needed to be carefully matched across the two services.
  • A request sequence flow diagram following data from the external client through the new service to the  existing end, and back, in a spreadsheet. Similar to the JSON model in some ways, but covering both services, losing the structure to focus on what data items were passed, and, much more visual. Request and response were aligned horizontally and time was represented vertically.  Additional richness came from colour to highlight particular data items or questions and columns for commentary. All these advantages came at the expense of significantly more effort to set up and drive.

And so I was thinking about the value of the models ...

Those models were all explorable to some extent, at the cost of the mental and physical friction of needing to keep track of context and state. In particular, none of them were parameterised and none of them updated dynamically. 

Some of the models were compiled and abandoned relatively quickly, perhaps having given some insight which prompted a change in direction or proving too costly to build and drive. The spreadsheet model was dropped and then returned to after iteration had happened elsewhere.

Despite the shortcomings, they were each helpful in facilitating conversation and understanding and iteration on the idea we were trying to bring to life. 

Interestingly, although they were shared, they served different purposes for different people and consequently had different value to different people too. The knowledge we carry with us in our heads can be reflected by the absence of that knowledge in the models we make.

And so I was thinking about the way we approached the models ...

We moved back and forth between the models as our conversations progressed. A simpler model might be used to sketch something out and then a more complex model would explore the detail around it.

At some points we cross-referenced the models with labels representing equivalent states but I doubt there was a time when any one of them told the whole story of our growing common understanding.

This isn't a surprise. In the context, there was an enormous amount of fluidity. If we noticed something that  we thought might not work there were multiple places that we could make a change, including the API specification itself.

We could also choose when to make a change. At one extreme, we could keep possibilities open, seek patterns, and look holistically for some pragmatic trade-off. At the other, we could make an immediate change, reduce local uncertainty, and see what fell out later. Both gave us a way to move past a problem, with obvious pros and cons. 

And so I was wondering whether there was any conclusion ...

Not really. I'm just trying to get my thoughts in order. Perhaps if you pushed me I'd say this:

  • none of these models were explorable in the Brett Victor sense, although we did explore the models extensively with the tooling and perspectives we had
  • the feedback was not always fast in the Jez Humble sense, but by making tacit knowledge explicit and talking it through we got extremely valuable feedback, and we acted on it.

Image: Brett Victor

Comments

Popular posts from this blog

Can Code, Can't Code, Is Useful

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "If testers can’t code, they’re of no use to us" My first reaction is to wonder what you expect from your testers. I am immediately interested in your working context and the way

Meet Me Halfway?

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Stop answering my questions with questions." Sure, I can do that. In return, please stop asking me questions so open to interpretation that any answer would be almost meaningless and certa

Testing (AI) is Testing

Last November I gave a talk, Random Exploration of a Chatbot API , at the BCS Testing, Diversity, AI Conference .  It was a nice surprise afterwards to be offered a book from their catalogue and I chose Artificial Intelligence and Software Testing by Rex Black, James Davenport, Joanna Olszewska, Jeremias Rößler, Adam Leon Smith, and Jonathon Wright.  This week, on a couple of train journeys around East Anglia, I read it and made sketchnotes. As someone not deeply into this field, but who has been experimenting with AI as a testing tool at work, I found the landscape view provided by the book interesting, particularly the lists: of challenges in testing AI, of approaches to testing AI, and of quality aspects to consider when evaluating AI.  Despite the hype around the area right now there's much that any competent tester will be familiar with, and skills that translate directly. Where there's likely to be novelty is in the technology, and the technical domain, and the effect of

Testers are Gate-Crashers

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Testers are the gatekeepers of quality" Instinctively I don't like the sound of that, but I wonder what you mean by it. Perhaps one or more of these? Testers set the quality sta

Postman Curlections

My team has been building a new service over the last few months. Until recently all the data it needs has been ingested at startup and our focus has been on the logic that processes the data, architecture, and infrastructure. This week we introduced a couple of new endpoints that enable the creation (through an HTTP POST) and update (PUT) of the fundamental data type (we call it a definition ) that the service operates on. I picked up the task of smoke testing the first implementations. I started out by asking the system under test to show me what it can do by using Postman to submit requests and inspecting the results. It was the kinds of things you'd imagine, including: submit some definitions (of various structure, size, intent, name, identifiers, etc) resubmit the same definitions (identical, sharing keys, with variations, etc) retrieve the submitted definitions (using whatever endpoints exist to show some view of them) compare definitions I submitted fro

Build Quality

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "When the build is green, the product is of sufficient quality to release" An interesting take, and one I wouldn't agree with in general. That surprises you? Well, ho

Make, Fix, and Test

A few weeks ago, in A Good Tester is All Over the Place , Joep Schuurkes described a model of testing work based on three axes: do testing yourself or support testing by others be embedded in a team or be part of a separate team do your job or improve the system It resonated with me and the other testers I shared it with at work, and it resurfaced in my mind while I was reflecting on some of the tasks I've picked up recently and what they have involved, at least in the way I've chosen to address them. Here's three examples: Documentation Generation We have an internal tool that generates documentation in Confluence by extracting and combining images and text from a handful of sources. Although useful, it ran very slowly or not at all so one of the developers performed major surgery on it. Up to that point, I had never taken much interest in the tool and I could have safely ignored this piece of work too because it would have been tested by

Am I Wrong?

I happened across Exploratory Testing: Why Is It Not Ideal for Agile Projects? by Vitaly Prus this week and I was triggered. But why? I took a few minutes to think that through. Partly, I guess, I feel directly challenged. I work on an agile project (by the definition in the article) and I would say that I use exclusively exploratory testing. Naturally, I like to think I'm doing a good job. Am I wrong? After calming down, and re-reading the article a couple of times, I don't think so. 😸 From the start, even the title makes me tense. The ideal solution is a perfect solution, the best solution. My context-driven instincts are reluctant to accept the premise, and I wonder what the author thinks is an ideal solution for an agile project, or any project. I notice also that I slid so easily from "an approach is not ideal" into "I am not doing a good job" and, in retrospect, that makes me smile. It doesn't do any harm to be reminded that your cognitive bias

Test Now

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "When is the best time to test?" Twenty posts in , I hope you're not expecting an answer without nuance? You are? Well, I'll do my best. For me, the best time to test is when there

Vanilla Flavour Testing

I have been pairing with a new developer colleague recently. In our last session he asked me "is this normal testing?" saying that he'd never seen anything like it anywhere else that he'd worked. We finished the task we were on and then chatted about his question for a few minutes. This is a short summary of what I said. I would describe myself as context-driven . I don't take the same approach to testing every time, except in a meta way. I try to understand the important questions, who they are important to, and what the constraints on the work are. With that knowledge I look for productive, pragmatic, ways to explore whatever we're looking at to uncover valuable information or find a way to move on. I write test notes as I work in a format that I have found to be useful to me, colleagues, and stakeholders. For me, the notes should clearly state the mission and give a tl;dr summary of the findings and I like them to be public while I'm working not just w