I was sitting and cursing out the interface of this new fangled integrated development environment (IDE) I was supposed to use, when it hit me – this was karma. Life had come full circle. I had become what I had not understood.
IDEs are code editors that are well integrated with other tools such as compilers, test runners, version control and linters. They make it easier to produce computer code. They are the means to an end. They are tools.
Five years ago, when my friend Nan first told me about this new open source IDE called VS Code, I tried it out and it immediately become the only IDE/editor I used. It blew away other editors and IDEs I had been using both in appearance and features. I even wrote a plugin for VS Code, adding support for a bioinformatics workflow language I was involved in. I became very familiar with VS Code.
When a new job, effectively, required me to use a different IDE (Let’s call it “Spider”), I struggled a lot. On top of having to learn new concepts, I had to learn how to do things in Spider. I had lots of complaints. Everything was in a different place and did things slightly differently. On top of that, Spider looked clunky and uninviting, like something from the dot-com era. I might be a mature software engineer, but I still liked shiny things. We all do, deep down.
When I learned that a bunch of colleague were working to migrate us to an editor based on VS Code I was, naturally, overjoyed. I signed up to be a beta user and bookmarked the project page. I couldn’t wait for the first real release. In the meantime, I unenthusiastically slogged on with Spider. As time went by, I became more used to Spider’s layout and integrations with version control, code review and linters. I became very productive with Spider. I began to like Spider.
About six months later, a big banner popped up on Spider. “Go use New Spider, made with VS Code,” it said (paraphrased, names changed etc.). I was excited! I was overjoyed! Full of enthusiasm, I immediately began to use New Spider.
As I tried to do my work with it, my enthusiasm steadily waned. “How do I do this? Why is this so hidden? Where is this button?” My productivity took a hit. The IDE looked like my old friend VS Code, but I found that I didn’t want it anymore, not for the work I was doing. I had gotten too used to Spider and how it hooked logically into all the other tooling. I had come full circle. And it reminded me of something that had happened in a previous job.
In this previous job I was involved in an effort to roll out a new editor for our bioinformatics teams. The old editor ran in production but had no support team – people familiar with the code base had moved on and had not been replaced. The new editor was being actively worked on and was built with newer frameworks and had a fresh appearance.
From my viewpoint, upgrading to the new editor was necessary from a business and technological standpoint, and it was, largely, just like the old editor with additional functionality, so people should be happy to adopt it. With this mindset, I was unable to understand the reluctance of my colleagues from the bioinformatics team to adopt the new editor.
Only when I was on the receiving end of this did I understand what was happening. People using the software don’t care about the fancy look and feel of the new tool. They certainly don’t care if it is written in Typescript, Javascript, Coffeescript or Indus Valley script. The software is a means to an end. It’s something that sits between them and their real work. Ideally it should be invisible – a seamless part of them that smoothly does what they want to do it. When we change things around, even moving one button from where it used to be, it’s like throwing a large spanner into the mesh of fine gears of a perfectly fine watch.
Another experience I had recently was even more instructive. Google changed the icon for several apps, including Calendar. I was introduced to this change one morning when I spent a panicked five minutes looking for my Calendar tab. My calendar tab is always open. It governs my work life. It was very disorienting for me to wake up one morning and find it missing from my forest of tabs. It was even more disorienting for me to not find it just after I opened it again. I finally realized that the icon had changed. It took me a week to get used to it.
Was this change worth it? I don’t know. I still use Calendar, so it didn’t lose a user. But nothing of value was added for me and I lost some productivity. There are probably books written on the sociology and economics of refreshing software interfaces without making actual improvements to its value, and I will not go into it here.
What I have taken away from these experiences is that changing the user facing aspects of software has to be approached with extreme caution and respect. It doesn’t matter if we think the new software is “better” than the old one. It doesn’t matter if the new software is, in fact, better than the old one on the off chance we could find some objective measure of better. The change is going to be hugely disruptive to the user.
In an ideal world we would first upgrade the “backend” – the internal machinery of the software, keeping the interface the same. Adding functionality to the interface is less disruptive than removing it, provided we don’t clutter up the old interface. Removing functionality is pretty disruptive and should be done incrementally. Changing layout is something that should be done only if there is clear evidence that the new layout makes things better.
As a post-script, users eventually adjust to the change. I adjusted to the change in the Calendar icon, I learned how to use Spider and I will eventually learn how to use New Spider. The screaming from the users eventually dies away into a rumble of resigned discontent and, if you actually, actually built a good product, the rumbles might change to rumbles of content. But this is no excuse to torture your users even temporarily.
Pages from the fire 