When you write a computer program, you?re providing instructions to one or more computers so that they can do whatever it is you?ve programmed them to do. In other words, you programmed the computers to have one or more capabilities.
According to Wikipedia, a capability is the ability to perform or achieve certain actions or outcomes through a set of controllable and measurable faculties, features, functions, processes, or services. But of course, you already knew that, as capability is a common English word and we?re using it in a perfectly common way.
But not only is the term common, the notion that we program computers to give them capabilities is also ubiquitous. The problem is, this capability-centric notion of software has led us down a winding path with nothing but a dead end to greet us.
The problem with thinking of software as providing capabilities to our computers is that the computers will only be able to do those things we have programmed them to do. If our requirements change, we must change the program. Only once we deploy the program, it becomes instant legacy ? software that is mired in inflexibility, difficult or even impossible to reprogram or replace. Hence the proverbial winding path to nowhere.
Our computers, however, are really nothing but tools. When they come off the assembly line, they have really no idea what programs they?ll end up running ? and they don?t care. Yet while we?re comfortable thinking of our hardware as tools, it takes a mind shift to fully grasp what it means to consider all of our software as tools.
Tools, you see, don?t have capabilities. They have affordances. Affordance is an unquestionably uncommon word, so let?s jump right to Wikipedia for the definition: an affordance is a property of an object, or an environment, which allows an individual to perform an action. The point to a tool, of course, is its affordances: a screwdriver affords users the ability to turn screws or open paint can lids, as well as unintended affordances like hitting a drum or perhaps breaking a window. But the screwdriver doesn?t have the capability of driving screws; rather, a person has that capability when they have a screwdriver ? and furthermore, it?s up to the user to decide how they want to use the tool, not the manufacturer of the tool.
The software we use every day has affordances as well. Links are for clicking, buttons are for pushing, etc. Every coder knows how to build user interfaces that offer affordances. And we also have software we explicitly identify as tools: development tools (which afford the ability to develop software, among other affordances) for example. The problem arises when we cross the line from coding affordances to coding capabilities, which happens when we?re no longer coding tools, but we?re coding applications (generally speaking) or solutions.
Such applications are especially familiar in the enterprise space, where they are not simply single programs running on individual computers, but complicated, distributed monstrosities that serve many users and leverage many computers. We may use tools to build such applications, but the entire enterprise software lifecycle focuses on delivering the required functionality for bespoke applications ? in other words, capabilities, rather than affordances. Even when you buy enterprise applications, the bulk of the value of the software comes from its capabilities. It?s no wonder we all hate legacy applications!
The challenge for the enterprise app space ? and by extension, all categories of software ? is to shift this balance between capabilities and affordances to the extreme of maximum affordance. In other words, instead of building or buying software that can do things (in other words, has capabilities), we want software that can enable users to do things ? and then maximize the affordances so that we have software smart enough to afford any action.
Superficially this goal sounds too good to be true, but remember what computers are for: they?re for running programs which give them instructions. In other words, computers are examples of maximum affordance in action. The next step is to build software with the same purpose.
