Safety Versus Freedom

A few years ago, I had an idea for some to-do list software. It managed my lists according to the Getting Things Done methodology, allowed me to view the to-dos in different ways and had workflows to guide me through things like the weekly review.

I had a great time programming it but I didn't like using it. It was quicker and easier to just use a text editor.

Years later, I realise this is a trade-off between safety and freedom. The to-do software gave me a set of actions to manipulate my lists that was safe. Using that software, I could only perform operations that resulted in a valid list of to dos. For example, I could:

• add items
• mark them as done
• assign a context or location
• set deadlines
• link them to a project

In a text editor, I could do all these safe operations but also anything else I could imagine. This extra freedom could be useful. For example, I could paste several items into an email to get an errands list on my phone. I could also paste a bunch of stuff from any source and format it into a list at my leisure.

However, the freedom was also dangerous in that I could mangle my lists into uselessness. I could set deadlines for the 31st February, enter prose between list items, even silly things like sorting all the characters in the file into alphabetical order.

My circumstances suited the software that granted the most freedom. I was a lone individual managing some low-risk, easy-to-edit lists. If thing were different, if there were multiple collaborators, if there were millions at stake then freedom would have become a liability. In those circumstances, I would have reached for software that gave the safety of data integrity, exposing well defined, safe manipulations of the data.

When designing or choosing software, it pays to consider the safety versus freedom spectrum. Typically, the software has to be safe enough to mitigate risk but offer enough freedom to get work done.

25 March 2017