Invisible Tech: How to Make the Invisible Visible
I’ve been ranting recently with the most perplexing battle cry: Down with no-code!!
Now of course I don’t mean to say that we should regress to the past (ahem, Supreme Court, what in the HELL is up with you right now?!) and cut off app building and automating processes from anyone who doesn’t know how to code (like myself). But I do want to discuss some nuances. The no-code movement has become so bombastic, so high on itself, and so ubiquitous, amplifying both the positive and negative outcomes and impacts of the movement.
The positive impacts are huge:
Access to create technology tools that before could only be created by developers/coders.
Access to the use of APIs for whatever purposes, but especially to create mission intelligence systems (the nonprofit version of business intelligence systems).
Access to design and build workflows and automated processes without a developer/coder.
There are negative impacts as well, and I was so delighted to recently have read Randy Au’s recent blog post about forgetting in data science. The article referenced an academic paper by Michael Muller and Angelika Strohmayer on this topic, which was truly a riveting read for me. The authors categorize and describe different kinds of “forgetting” in data sciences and the positive and negative impacts of that forgetting. I see a ton of overlap with the “no-code” movement as well as discussions I have been involved in about invisibility in data and technology.
Randy adds extremely relevant thoughts on the role of Context in forgetting in data analysis. For him, a way to address some forms of forgetting is through context - which he describes as “documentation for our data science work” that “needs to move along with the data” and be present with it at each stage of its life cycle. We may not need to see it right in front of us, but it needs to exist and be accessible in order to “remember” this Context at will. This view is a great companion to a concept from Muller and Strohmayer’s paper - a type of forgetting called the strategy of “separation of concerns” which is practiced by developers to “focus on their immediate task while encapsulating non-focused complexities outside of their current scope of attention and action.” The authors define encapsulation as a kind of “reversible” forgetting, because “if complexity is forgotten through encapsulation in a particular function call, a computer scientist or engineer can usually access the source code of the function - thus effectively remembering the complexity upon need.”
But for the user of the no-code technology, there is no such access to the complexity - the context - of the software. The makers of these technologies work very hard and with very good intentions to cloak what is technically going on behind the beautiful UIs and Widgets and drag-and-drop components. And their advertisements and demos are chock-full of funny cartoon drawings of people magically performing computer tasks and working with joy as their softwares make your work, whatever that work entails, as easy as snapping a finger. They make invisible the fact that there is an immense amount of complexity happening in their technology, and that being keyed into at least some part of that is important. Unfortunately, the invisibility means there is no “reversal” of forgetting - no opportunity for learning about the complexity.
This read is so important for all users of data - I hope someone takes this paper and makes it into some sort of viral flash mob performance so that the message and learnings from it would be more widespread and accessible to those who don’t want to read an academic paper. I’m feeling very grateful that Randy’s newsletter tipped me off to read it.
Muller and Strohmayer and Randy have laid out excellent information and insights about remembering and forgetting in the data sciences, and I am using their research as a lens through which to view the no-code movement. It is also a good lens through which to view the impacts of get-out-of-spreadsheets software, and I will address both going forward. Here are my thoughts on these movements and softwares:
NO-CODE IS A FALSE GOD.
Everything no-code happens because programmers wrote the code that is referenced when a person drags-and-drops or chooses from a selection of components or creates a workflow. Not only that, a programmer needed to write code that would build the interface through which others perform “no-code” actions. It is a form of making code invisible, which usually isn’t really a concern - for the most part people aren’t digging into the code for how their softwares work or hitting F12 on their keyboards to see the HTML of the website that they are on. But these movements also serve to make the people who put their time, energy, and care into this amazing code become invisible and forgotten. There are already barriers to connection that exist between developers and users of software and data - often they don’t share the same language around a technology, each using their own terminology, it can be difficult to embody beginner’s mindset when developers have the chance to share their knowledge and skills with their non-developer colleagues, many people come with biases and preconceived notions about who a “developer” is and how they work and communicate, etc. Phrases like “no-code” and the act of making developers invisible make it harder for people to see an example of the kind of work available and fun for someone who does not know how to code, but who is interested in learning. Programming and programming languages have an impossibly big influence on our world and society, and knowing them should be a skill and pathway that is available to and encouraged for everyone.
SPREADSHEETS ARE HERE TO STAY AND WITH GOOD REASON.
Spreadsheets are one of the most effective and impactful educational tools and references for visualizing what the storage of data in a database “looks” like. Most everyone knows what Excel or Google Sheets looks like, with their familiar criss-cross of lines, letters, and numbers. Spreadsheets are excellent playgrounds for people to make the invisible visible. For example - in many cases a person can write a formula that will count their data (how many people live in such and such state) and they can filter their raw data set using the filter arrows (not the formula, although that’s a great joy as well) to see if the result of their formula matches what they can see in the filtered data. This method both makes visible the subset of data that we want to see, uncluttered and made visible by filtering out all other data, AND makes visible any potential differences in expectations for what data the formula is meant to be referencing and returning. By marketing themselves as “escapes” from spreadsheets, these software companies are inadvertently making their underlying databases more invisible and erecting roadblocks where a person might otherwise better understand and learn their software if they were allowed to see the very spreadsheet-y like nature of how their data is stored and referenced.
The paper by Muller and Strohmayer began with a poem:
...and our songs about the stories we’ve forgotten;
and all that we’ve forgotten we’ve forgotten...
–Pádraig Ó Tuama
Forgetting can be a choice, and we can forget what we have chosen to forget. We can set aside the complexities to be able to do the work. At the same time, there must be a way to “reverse” the forgetting, a way to make the invisible visible. This visibility won’t come from a “no-code” movement. It will come from more access to information, education and skills about programming languages and APIs - about complexities. Not everyone needs to be a programmer or a coder. But everyone should have visibility into the way that code works for their system or organization. The access and encouragement to learn more about data and technology, including more about programming and developers, should be available to all users, to all people. We shouldn’t help people forget about the complexities that are involved in their systems. Instead, we should encourage curiosity, make space for learning & development, and support people along their data & technology learning path.
