Social and Cognitive Prostheses

Person with calculator watch on wrist
Photo by Andrik Langfield on Unsplash


Value in software can be assessed by it’s monetary worth, perceived importance or merit to someone. The primary way this value is derived from software is for it’s ability to help someone solve a problem, complete a task, achieve a goal or otherwise be more productive (Page, Johnston and Rollison, 2009). In this way, the software acts as a prosthesis.

Imagine that you had lost a leg. To help you walk, you would rely on a prosthesis—the modern-day steel-and-plastic equivalent of a wooden leg. This prosthesis makes up for a lack, allowing you to accomplish a task (in this case, walking). Not only do people rely on physical prostheses, but they also can rely on cognitive ones. For instance, an electronic calculator is a cognitive prosthesis, filling in for a lack so that you can accomplish a specific task (Kosslyn and Miller, 2014)

Likewise little or no value may mean it doesn’t help someone solve a problem, complete a task or achieve an goal, or causes further hindrance or damage. For example, a prosthetic leg could be too heavy or not articulated enough to be of value. It may even cause harm through injuries. A calculator application may give incorrect results or be too difficult to use. This may cause an accountant to lose an important customer. This doesn’t just affect users, both items may end up being failed projects for business stakeholders.

The software only helps or hinders and isn’t completing the task itself. A prosthetic leg won’t replace the entire action of walking and a software program won’t replace a human being in solving a human problem.

What, say, a pocket calculator does shows that it does something different to a human calculator — for example, when approximation is called for; second, humans make up for what the calculator fails to accomplish, often without noticing that they are doing it — the computer is a social prosthesis (Collins, n.d.)

Customers, end-users and business stakeholders are three classes of people who value software or are affected by it, but there are others too. For example:

  • Professional reviewers and press matter, because reviews or news reports could make or break sales of the software or the reputation of the organisation creating it.
  • Governments matter, because they have the power to fine and prosecute where software or companies have broken laws.
  • Society-at-large matters too. A problem in the software of a nuclear power plant could cause a melt-down that brings loss or harm to the power plant owners, workers and software vendor, but the impact to other people goes far beyond that! No-one wants harm to come to people in that way, so everyone matters when it comes to nuclear safety, not least because it would lead to litigation against the company too.


Tools and Applications

Photo by cottonbro from Pexels


Another way to think about the value of software is as a social or cognitive tool. The software is an extension of the human mind in the same way that a spanner or whisk is an extension of the human hand. Each is specially designed for purpose of tightening bolts or scrambling eggs respectively. Application (often shortened to “app”) is another popular way to think about software as something that’s applied to solve a particular problem, task or completion of a goal, and is therefore congruent with the definition of value used here.



The capability of software to fulfil a purpose or objective isn’t the only way value can be delivered or threatened. What makes a sports car better than a regular car? Or a restaurant meal worth paying extra money for in comparison to home cooking? Both cars can fulfil the purpose or objective of getting from A to B. Both meals will fulfil their purpose of supplying energy and nutrients to someone.

Capability of software is built upon functionality. From the user perspective, functions are end-to-end operations with a single user input and output. Achieving capability quality involves the execution of one or more user functions. However there are different dimensions to quality that can still affect value in other ways. These are built upon functionality so are referred to as parafunctional (or non-functional) quality dimensions (Kaner, 2010).

Even though digital computers have the same capabilities, even though they can do nothing beyond the primitive computing machine devised by Alan Turing, the speed of the processor of course ultimately affects the overall usefulness of a computer system. Any computer that’s slower than the human brain in performing a set of calculations is useless (Petzold, 2000)

Performance is an important parafunctional quality dimension. A software product, system or service may do the job, but if it does it too slowly to be useful, or does it slower than another rival product, its value to someone is going to be low. However performance quality can’t exist without capability quality (functionality). Performing a task quickly or slowly can’t happen unless it’s first possible to complete the task.

Click here to see a full list of quality dimensions.



Value in software is primarily derived from its ability to help solve a problem, complete a task or achieve a goal. In this way, software can be thought of as a social or cognitive prosthesis or tool, or simply an application – something to be applied to solve a particular problem. However capability isn’t the only way in which value is achieved or threatened, and testers must consider many other parafunctional dimensions to value and quality.

Value can also be characterised by positive emotions and feelings:

  • Feelings & Emotions - Focus on people's feelings as the indicator to quality but be careful to avoid being fooled by illusions



  • Collins, H., n.d. Key Concepts [online] Harry Collins. Available at: Link
  • Kaner, C., 2010. BBST Foundations 1B: Overview and Basic Definitions in Software Testing. [online] TestingEducation. Available at Link (t.i. 8m34s)
  • Kosslyn, S. and Miller, G.W., 2014. Social Prosthetic Systems. [online] Psychology Today. Available at: Link
  • Page, A., Johnston, K. and Rollison, B., 2009. How We Test Software at Microsoft. 1st ed. Redmond, WA: Microsoft, p. 297
  • Petzold, C., 2000. Code: The Hidden Language of Computer Hardware and Software. 1st ed. Redmond, WA: Microsoft Press, p.259.

Updated: 16/10/2021

Leave a Reply

Your email address will not be published.

You may also like these