Cautionary tales about using software tools that can be taken from you #

When you're choosing a tool -- particularly a software tool like a programming language -- it's important to choose tools that you control; that is, tools that cannot be taken away from you. Here are a couple cautionary tales from my own career about this.

Mathematica and LiveGraphics3D #

Back in the early 2000s, I was a graduate student at the University of Minnesota and was a TA for multivariable calculus course. This course had "labs" where students would use Mathematica to work through some problems and write up their findings. The Mathematica notebooks were a mess, hard to use, and I worked with several other TAs to make them better, more interactive, and better for the students.

But we also wanted to write regular web pages for some topics. (Remember when that was A Thing? Like, editing an HTML document? Good times. (Seriously, I do think those were good times.))

One key thing we used was LiveGraphics3D. This was a Mathematica module that would take 3D graphics produced in Mathematica and produce a Java applet that you could put into any web page. That applet was completely independent of Mathematica, so it was very convenient for us to make our web pages as we liked. Anyone with a web browser could see and interact with and use our cool 3D graphics. It was great!

Then the university upgraded to a new version of Mathematica. Wolfram had seen the success of LiveGraphics3D and wanted to make people use their own "Mathematica Demonstrations" or whatever it was. This was a very nice interactive feature, but it only ran inside Mathematica. As part of the upgrade, Mathematica now didn't work with the existing LiveGraphics3D module/plugin.

So now we couldn't make new web pages, or update the existing ones. We wanted to make web pages that anyone could just read. Even if someone had access to Mathematica, we didn't want to make them download a notebook and run that.

The new version upgrade was automatic as part of the university's Mathematica license. We didn't have any control over it. We were using a tool that we didn't control, and it was, in effect, forcibly taken away from us.

Keep in mind that this was to the detriment of our students -- and the random people who read our web pages to learn about calculus.

My own research and losing access to Mathematica #

In grad school, I did a lot of my research using Mathematica to confirm conjectures, find patterns, and so on. My advisor used it a lot, and was really good with it. I wrote thousands and thousands of lines of code, and likely spent thousands of hours making my own set of functions and such that helped me prove theorems and such.

Then I moved to KAIST for a postdoc...and didn't have access to Mathematica. I didn't have any funding, so I couldn't buy my own license, and didn't want to pay for it myself. I also didn't want to have to do that all again when I left KAIST, and I didn't want to have something like the LiveGraphics3D thing happen again where Wolfram made some change that broke all my code.

Compare that with some code I had written in Haskell. That code still worked, and the Haskell community cares about backwards compatibility -- and even if some new version of Haskell broke my code, I could still use an old version. Haskell -- and the value of the work I had put into it -- could not be taken away from me, but Mathematica could be taken from me. I had thousands of lines of code that were now just weird text files.

It's just not access, it's switching cost #

Bear in mind that having access to a tool isn't just about access -- it's about the switching cost to an alternative.

Imagine you use tool A. It's okay, but you get stuff done with it and it works.

Now you lose access to it. But in its place, you have access to tool B, which is better. Great, right?

In some ways, yes -- but you'll incur switching costs. You have to rewrite code, you have to relearn keybindings and workflows and such.

And you may be forced to do this on a schedule you don't want.

Investing resources into better tools is a good idea (provided that the ultimate cost/benefit calculation works out) -- but no one wants to have to do that investment on a timeline not of your choosing.

Imagine you're halfway through some development project, and some little tool you are using suddetly is no longer available to you. But there's now a better thing!

Sure, the New Hotness may be better -- but do you want to switch now? Maybe you need to ship soon, or are almost done. You don't want to delay your current work to get the new tool working. You want to have the freedom to pay those switching costs and do the investment in the better tool when it works for you.

Also see Karl Voit, referencing Jack Baty on the cost of switching.

Tools that can't be taken from me #

Since my experiences in the aughts, I now choose tools that can't taken from me; tools that I control. In general, this means open-source software, and using open standards.

Notable example: Sage #

For some years I was involved with Sage, and open-source mathematical software system. It combines a huge number of open-source mathematics software into one nice Python-based interface. n Everything is open source, so if you do research, writing, or anything else using Sage -- you can always have access to that! It cannot be taken away from you.

Even if a new version of Sage changes something that breaks your stuff -- just keep using the old version! Or better yet, contact the Sage team and submit a patch or pull request that makes the new version meet your needs.

Emacs and other tools #

I now work in industry, but I use emacs at work (along with, yes, a lot of proprietary tools). But emacs can't be taken away from me; all my configuration can be taken with me. All the time I've spent learning emacs will continue to benefit me...well, given how old emacs is and how popular it remains, it seems like I can safely say emacs will continue to benefit me for...decades? The rest of my life, maybe?

Back in the day I was also a huge user of LaTeX, TikZ, Beamer, and related document tools. I haven't used those in years -- but I still can, any time I want.

Switching cost turns into exponential benefit #

When a tool is taken from you, you incur a switching cost.

When you get to continue using a tool, you get a exponential benefit from time invested in learning the tool!

If I spend an hour learning how to do something in emacs, I get to continue benefit from that time investment...basically forever. The one-time investment in learning repays itself over and over again.

What's more, since I can continue using the tool, I'll likely be able to use my new knowledge or skill to learn yet more or gain more skills! And then use that new knowledge to...and so on.

This matches Terry Tao's advice/observation -- I don't have the exact link, but he's observed that if you become, say, 5% better each year, in 14 years you'll be twice as good. (Okay, fine: $100 \ln 2 / 5 \approx 13.863$ years. Enjoy those extra 50 days. 🙂)

Physical tools / devices #

Everything I've written here applies to physical tools and devices, too. For example:

Raspberry Pis: a freezer door sensor #

We have a freezer in our basement and I wanted to add a sensor that would alert us if someone left the door open.

I wanted an alarm that would sound when the door was open for a bit. And maybe also something that logged the door openings and closings, so that if we did leave it open, we might know how long it had been open.

There are commercially available things that do this, and no doubt are wifi-enabled, log data to the cloud and so on -- but in the end, I used a Raspberry Pi, a reed switch, and a basic buzzer. I wrote Python code that detects when the door is open too long, and which also logs openings and closings to a little database.

I could have saved money and time with a commercially-available tool -- but what if the logging cloud service gets shut down? What if it breaks and there's no support?

By making my own tool, I have something that can't be taken away from me, and which I can fix or modify as I like. I hope I've convinced you that this kind of tool is superior to those that are out of your control and can be taken from you.

See Karl Voit's "How to choose a tool" for more general advice on choosing a tool -- my advice here is just one factor.

To come: choosing data #

Tools are one thing, but what do you do with them? You do things to data!

The analogous principle for data is: choose data formats that can be used with many tools. See this followup post: Choose data formats that can be used by many tools.