Are You an Efficient Developer? Then AI Is After Your Job

In my previous post, I wrote about finding your competitive advantage as a software developer in a world of encroaching AI. I believe there are a few questions more relevant in the coming decade, so I like to elaborate on the topic in this and my next postings.

You can only maintain such a competitive advantage if you focus on tasks that humans by their very nature can do better than machines. There are two necessary properties of software development that illustrate and coincide with the relative strengths and weaknesses of humans versus computers They are efficiency and effectiveness, and will be the focus of today’s post. I give credit to Uwe Friedrichsen for pointing out this distinction in a recent blog.

Chess and Submarines

Who would be among the most esteemed persons alive, in science, art, and sports? A poll taken in 1985 might include physicist Richard Feynman, actor Meryl Streep, philosopher Susan Sontag, and probably also Gary Kasparov, the young Russian chess grandmaster and new world champion.

Several years before, you could already practice chess against a variety of digital opponents. The algorithms in these toy devices must seem unsophisticated now, and their feeble computational horsepower laughable. But an early AI they certainly were, even when they were no match for serious human players, least of all a grandmaster. Moore’s Law quickly took care of that. In little over a decade (1997) the same world champion lost against IBM’s Deep Blue team.

This 25-year-old defeat of man against machine did not make us unduly worried that AI would soon take over in some Terminator-like dystopia. If anything, it confirmed that chess is hard for humans and easy for computers. “The question of whether a computer can think is no more interesting than the question of whether a submarine can swim," according to Professor Dijkstra. True, you cannot compare a computer winning at chess with the way Magnus Carlson does it. The way a nuclear submarine displaces water is equally incomparable to how a shark does it. Machine intelligence, whatever way you define it, is only externally analogous to what goes in a human brain. It’s the effect that counts. Yet, I disagree with the suggestion that the question of a thinking computer is uninteresting. 

The Journey and the Destination

According to the Longman dictionary, effectiveness is the fact of producing the result that is wanted or intended; the fact of producing a successful result. Checkmate is such a successful result. Efficiency is the quality of doing something well with no waste of time or money. Of the infinite number of possible matches, fool’s mate is the most efficient one.

Apropos: note the purely economic thinking in the definition. Only a “waste of time or money” is considered. Had energy been a factor, no human invention would be efficient compared to its biological counterparts in terms of raw energy consumption.

Once the computer can do a job effectively as well as efficiently, humans have made themselves redundant from a cold economic perspective. You’re welcome to dabble for your own enjoyment but don’t expect a paycheck. People still enjoy chess because it was never a means of survival. We don’t need it to grow food or build houses and only a small elite of the best players make money from it. Had chess been a production resource (like land and labor), human chess players would have no competitive advantage.

Being effective means arriving at a satisfactory result. We either have it, or we don’t. You can exceed expectations, or fail miserably to any degree, but it’s the binary thumbs-up or thumbs-down that counts. Efficiency is about how you perform the constituent tasks. It’s a quality that allows more leeway. Parts of the process can be less optimal than others and still contribute to an effective result. Other terms that coincide with the dichotomy are the what (and why) versus the how. It’s doing the right thing versus doing things right. It’s the destination versus the journey.

Both are necessary. Being consistently inefficient will bankrupt you before long, but being ineffective won’t even get you a first sale. Therefore, no serious software project should be undertaken without a clear definition of the effectiveness we seek to achieve. Only improvisation genius Keith Jarrett could get behind a keyboard without a goal in mind and still produce a masterpiece – but that was a piano keyboard.

Efficiency Is Relative, Effectiveness Subjective

Effectiveness is fuzzy, unpredictable, and subjective. What do Seinfeld, Monty Python, Bohemian Rhapsody, and Star Trek have in common? They are all beloved popular classics that most people, including the critics, didn’t much notice or appreciate when they first came out. It’s no wonder many products fail, no matter how much market research you throw at it. There is no formula for creativity and no telling how people’s tastes can change. Efficiency is far less infuriating. The customer couldn’t care less what build tool or IDE the Spotify app was made with. It leaves no trace in the final product.

Modern products are a complicated assemblage of parts from various suppliers. We choose parts for their efficiency in the hope they make an effective product that customers want to buy. But while each part is already effective from the supplier’s perspective when they make a sale, it only becomes efficient when it’s the right part. This extends to more than physical parts.

Here's a real-world example of semi-conductor giant ASML, near my hometown. Morning traffic to the campus is hell, and public transport is only served by buses. The city council wants to lay a new bicycle lane to entice commuters living in a ten-mile radius to cycle to work. The goal is to get everybody to the office safely and fast by relieving the congestion for whom bicycles are not an option. The contractors building this road have no urgent stake in this efficiency drive, much less bicycle manufacturer Trek or Shimano, who supplies the gears and brakes to make the bikes run smoothly. But they all contribute to the effectiveness of the new road. Efficiency is relative, and effectiveness subjective.

You get the point. Software is no different. The average enterprise product consists mostly of other people’s code you and your team can’t control (99.9% is a safe bet, certainly if you count the cloud stack you deploy to). Any component can be efficient in some places and useless elsewhere. A highly optimized caching mechanism backed by a dedicated Oracle enterprise is still a waste of money if you only need it to remember fifty numbers for an hour.

Efficiency is about experimentation, making small tweaks, and swapping out slow/expensive components for better-performing ones. It’s a complicated, data-driven domain where computers feel right at home. Judging the effectiveness of software on the other hand is complex: it comes down to whether it ultimately makes the recipients happy. Who else but other people are qualified to answer that question and make the decisions?

In the next post, I will focus on requirements/specification versus implementation and how they coincide with the efficiency/effectiveness distinction. In part three, I’ll discuss the famous alignment problem. Even humans fail at aligning software goals with their own interests and build expensive failures. How can we expect machines to do better? Then in part four, I will address our love of specialization, coding for coding’s sake, and why that will no longer be a competitive advantage soon.