Posted on

The THX 1138 Rule

In the 1971 movie THX 1138, George Lucas’ first feature film, the title character gets in trouble with the law when he gets his girlfriend, LUH 3417, pregnant. In the highly regimented society in which they live, relationships like theirs are illegal. The authorities throw him in jail and redesignate LUH 3417 so he can’t find her again.

THX 1138, along with a couple of other escapees from jail, look for a way out of the subterranean complex where their society lives. Ultimately, THX 1138 is the last of the escapees still at large. The robot cops try to convince him to return with them, but he refuses. When the pursuit exceeds 6% of the budget allocation for chasing escapees, they let him go and he reaches the surface.

The question you may be asking is, “What does that have to do with anything?”

Well, there’s a rule of thumb I follow when evaluating and trying out software products and software development tools. I call it the THX 1138 Rule. It means I will invest a reasonable amount of time and effort to install, configure, and learn to use a piece of software – and no more.

Okay, but where, exactly, is the point of diminishing returns? Clearly, it’s reasonable to expect some level of effort and some learning curve time to start using a software product effectively. How do I judge when “enough is enough!” and it’s time to set the product aside and look for another solution?

That judgment will necessarily be subjective. I think it depends on (a) where a person stands with respect to certain ideas, and (b) how difficult it is to install, configure, and use the software in question.

Personal Thing #1: The Fiddler Spectrum

Some developers enjoy fiddling with their tools. They will happily spend 50% of their time or more tweaking configuration settings and trying out different options.

Others do not want to make a career out of setting up and adjusting their tools. They want to use their tools to do “real” work.

This is not a binary thing. Each of us falls somewhere along a spectrum between the two extremes. Those closer to the first extreme are likely to be willing to invest more time and effort in getting an unfamiliar tool working than those closer to the second extreme.

Personal Thing #2: The Determination Spectrum

Some developers already have favorite tools – especially editors or IDEs. When they need a solution to a development challenge, they will spend considerable time experimenting with a new extension or plugin, or with complicated configuration settings for their favorite editor/IDE. They are determined to use this particular tool to solve every problem.

Other developers are not married to any particular tool stack. They are willing to (and routinely do) use different tools – including multiple editors/IDEs – to address different problems and/or to support development work in different languages. They will not be willing to spend as much time trying to coerce a new extension or plugin to fit into any particular tool stack.

This, too, is not a binary thing.

Software Thing #1: Learning Curve

All software requires its users to learn something before they can make effective use of the product. The question is, “How much learning curve time am I willing to suffer through before I reach a point where I’m making reasonable use of this software?”

It isn’t a question of “mastery.” It’s a question of getting familiar enough with the software that we aren’t constantly stumbling. There are development tools that take years to “master” but that don’t take years to reach a reasonable level of proficiency.

Software Thing #2: Transparency

The word “transparency” is overloaded. Here, transparency refers to the degree to which the software forces you to pay attention to it instead of to the work it’s supposed to be helping you perform.

So the point of diminishing returns depends on the developer as well as on characteristics of the tool in question, particularly from the point of view of “user experience.” Does the software require a lot of attention, and does the developer enjoy giving the software a lot of attention?

Who Am I?

I don’t mind a little fiddling, but I don’t want to spend the majority of my time on it. So, on the first spectrum, I’m closer to the “just use the tool to get work done” end of the spectrum; but I’m not all the way at the end.

I prefer using the tool(s) that are best suited to each task. I have no single favorite development stack that I insist on configuring to support every type of work, no matter how long it takes.

So, when doing Java development, if it’s a SpringBoot API kind of thing, I’ll choose Spring Tools (previously Spring ToolSuite), an Eclipse-based tool. If it’s Android development, I’ll choose Android Studio. If it’s generic Java development, I’ll choose JetBrains IntelliJ IDEA.

Tools like Vim/NeoVim, VSCode, and Sublime Text don’t quite handle complicated Java projects, in my opinion. Maybe I’m the problem – the leading vim/neovim plugins for Java just don’t do what their READMEs say they will do, and what other users say they can do, when I try to use them. They can’t even find Java executables on the path.

And if online questions and answers are any guide, no one else on the planet has this problem. It could be a PIBKAC problem. Wouldn’t be the first time.

I know there are people out there who have managed to wrangle neovim into a pretty decent Java development tool, but God only knows how they ever succeeded. I haven’t been able to get Java set up with that editor in a way that could support professional development work.

Java is kind of a special animal. Classpath issues, version sensitivity, collisions in transitive dependencies, finding things in the code base, safe refactoring, building different kinds of jars…the features in the “full-blown” IDEs handle so many of these details automatically that it’s a no-brainer to choose one of them for Java work.

And yet, I’m a minimalist at heart. While I’ll usually choose a “full-blown” IDE for Java, I’ll choose VSCode or NeoVim for most other kinds of software development. They’re both great for .NET, Node, Ruby, and Python development, as well as for editing HTML, CSS, Markdown, XML, and JSON; and VSCode has extensions available that make it suitable for mainframe work.

Good, Better, Best

Thinking about this aspect of software reminds me of something the US department store chain Sears, Roebuck & Co. used to do (and maybe still do, for all I know). They would identify their products as falling into one of three categories: Good, Better, and Best.

To me, software in the Best category installs without additional effort on my part beyond clicking on an installer or entering a single command, like “apt install” or “brew install.”

If there is any configuration to do, it is well documented and not too extensive. The initial learning curve can be measured in minutes to hours; not in weeks to months.

When using the software, I find most of the key features are intuitive and obvious, most of the remaining features are readily discoverable, and everything else is documented plainly and accurately.

The user community around the tool doesn’t answer questions with a dismissive “RTFM” or a bemused “Gee, that shouldn’t happen!” If the manual were any good I wouldn’t be here, and of course that shouldn’t happen; that’s why I asked, after all.

Tools I use frequently that I consider to be in the Best category include: Camtasia (TechSmith) for editing videos; MuseScore (Open Source) for writing music scores; VSCode (Microsoft/Open Source) for doing software development work; VMware Fusion and Workstation for virtualization; and any of the spreadsheet programs, Microsoft Excel, LibreOffice Calc, or Google Sheets.

All those tools are easy to install (or accessible online), have short learning curves, are well documented, and do what they claim they will do in a way that doesn’t divert my attention from the work at hand.

Features that aren’t immediately obvious are easy to discover: how to apply noise reduction in Camtasia, how to define a custom time signature in MuseScore, how to get a VSCode extension relevant to my current project, how to increase the size of the virtual disk in VMware Fusion or Workstation, or how to move a block of rows up or down in a spreadsheet.

It isn’t necessary to read a manual or slog through StackOverflow answers to find out how to do those things. You can figure them out by poking around in the UI for a minute. You can just work, and keep your task in the foreground of your brain, to the extent that you forget the tool is even there – all you’re aware of is your work.

In the Better category are software tools that have longer learning curves or that require significant customization or configuration to make them useful. Some tools in the Better category may support your work flow very nicely most of the time, but occasionaly hang or pause to perform some under-the-covers magic. This pulls your attention away from your work and toward the tool itself. Others may perform their function well, but are a little clunky to use, even after you’ve climbed the learning curve to a reasonable extent.

Examples of tools that are useful, but have quite steep learning curves and/or require significant configuration include Emacs and Vim/NeoVim (text editors for software development), and certain IDEs (integrated development environments, also for software development).

Tools that interrupt your train of thought to perform under-the-covers magic whenever they feel like it include JetBrains IntelliJ IDEA, the Eclipse IDE and custom bundles built on top of it, and Microsoft VisualStudio. It seems they spend most of their time syncing or indexing or just starting up.

All of those IDEs support so many features and can integrate with so many different kinds of external software that they “forget” what’s going on – they don’t reload a component that you changed in the editor, or they lose track of a server they’re supposed to be connected to. Sometimes all you can do is restart the thing. IntelliJ IDEA even has a menu option to reset itself.

They also have numerous configuration settings that are not easy to identify (based on the names the developers gave them) or locate in the menu hierarchy (which I assume is organized according to some kind of rational thought process, however non-obvious).

Some software works well but is clumsy to use. I would call these Better rather than Best, per the Sears model. If they could improve the user experience, they would qualify as Best.

The GIMP (GNU Image Manipulation Program) falls into this category. It works but is not easy to use, and never becomes particularly easy to use even after you’ve learned it well.

The Internet videoconferencing tool, Zoom, also falls into the Better category because it is clunky to use. It works, but also forces its users to pay attention to it instead of to their meeting. People often have to pause their discussion while someone figures out how to share their screen or use the whiteboard feature or find the unmute button or some other detail. Often people have trouble with audio – the same setup that worked last week no longer works, and you haven’t changed a thing.

What’s my THX 1138 rule?

As for me, I’ll use a Good tool if there’s no alternative, or a Better tool if there’s no free or cheap alternative. But I prefer a Best tool, according to my own preferences. What does that mean (to me)?

It means the tool installs correctly according to its documentation. Period.

It means any configuration required of me only amounts to a few lines in a configuration file or a couple of clicks on a configuration dialog; and that whatever the documentation claims will work actually does work, without further research or tweaking on my part.

It means I can learn to use the tool effectively in a fairly short time – a couple of days, maybe. Mastery is a different issue; I’m only talking about being able to use the tool to support the tasks I require of it.

It means the tool is transparent to me while I’m using it; my brain can focus on the work I’m trying to do with the tool, and not the tool itself. It doesn’t interrupt me by suddenly starting to “index” or “sync”, like IntelliJ IDEA or Eclipse. It doesn’t take a lifetime to load a project, like VisualStudio. It doesn’t arbitrarily move itself around within the editor window, like the NERDTree plugin for Vim and NeoVim. Most of the time, the software basically just works.

So if a tool is any more troublesome to install and configure than that, and any clunkier to use than a viable alternative, the THX 1138 Rule kicks in. I only have so much patience budgeted for chasing misbehaving runaways.