The Fast Pencil Fallacy in Software Development

by Zoran Horvat
June 16, 2020

A program is not a very fast pencil.

Software operates on different plane when compared to pen-and-paper business. It is the duty of software developer to avoid the trap of aligning software with principles of a traditional business.

In this article, we will describe how the fast pencil fallacy becomes reality in a common software development project. After that, we will explain how that fallacy can be avoided.

Understanding the Problem

To better understand how brand-new software inadvertently becomes a fast pencil, we need to understand the process of delivering software. It all begins with the customer, probably feeling lost in the process of defining requirements – desires if you will – specifying what the future product should and should not do.

The customer is running a business, in a way which has remained the same for a hundred years maybe. They are using very primitive tools, quite different from the tools we use in software development. They are accustomed to using a pencil.

And what they ask a software developer to do, is to come up with a nice and square software to enhance the way their business is run. And indeed, developer comes up with a piece of software, which is meant to replace that traditional pen-and-paper business. That is the moment when magic happens in its least desired form, because the customer, no matter how hard they tried, will never be able to see the difference between the two, the pencil and the software.

They will normally see the program as a very fast pencil. They will invariantly look at the program as a fast replacement for their traditional business. And that is the problem. Modern software development practices based on accepting customer’s requirements and implementing them to the point where any distinction between software and a pencil disappears is the root cause of bad software design.

If you try to oversee software development today, you will see programs of all kinds working exactly the same as the pen-and-paper business they are addressing, with only one tiny distinction, and that is that software is automated to a degree. That is precisely why customers will keep seeing software as their very fast pencil.

Do you want to develop that? No, you don’t! But what will you do instead? How will you respond to customer’s requirements? To answer these questions, we need to return to place where it all begins: To the bare business.

Spoiler ahead. When developing software, we will not regard customer as the source of truth. Not everything your customer will tell is correct. We will now look at software development from a different perspective.

Avoiding the Fallacy

To understand how software should be developed, we will once again start from the customer, who is utterly lost with so many thoughts in their head. They have a business, that’s the fact. But that is not relevant to software development, because nobody wants to have a business. People want to have a vacation, not a business. Something else they have is of our interest instead, which remains to be discovered.

In software development, voyage begins with understanding that customer, who owns the business, has something else of importance. That will probably be the element you have never met in your programming life. They, customers, have the problem. They have something that is hurting them, or hurting their own customers.

Their entire business is built around methods of addressing that problem. That is the whole point of businesses, and the reason why it was said above that nobody wants to have a business. Customers want to solve the problem for their own customers and to make money by being successful at it.

Where does the software fit into this picture, then? Software comes as a representation of a solution to the problem. You would move the problem away from the customer and put software in between. That makes software a layer of abstraction between the user and the problem.

At this point, we are switching to term user, not customer anymore. Basically, user is the one who is using software, and customer is the one who is paying for the software to be developed. This definition may not cover all angles, but it will be sufficient to understand the explanations that follow.

When put that way, users will use the software, and software will abstract away that pointy thing below which is hurting them. The rule of the game is to remove the problem from user’s view, and to replace it with an abstract representation of the problem, so that software can act as an automated solution to the problem instance.

Finally, there comes the question of avoiding the fast pencil fallacy. You will avoid it best if you understand that software itself is of no interest to the user. What is of interest, however, is the way the user will send commands to software. That is how user is controlling the abstraction of the problem. You will need to think about how to best implement commands, then.

Software will ultimately produce one tiny item, and that is the only thing your user will ever care about. That is the output, the product of applying software.

In effect, the user will only be concerned with giving commands to software and collecting the result. And even those commands will be of little concern, with that result of applying software remaining the only thing that is useful to the user. Software is not important. Problem is not important. Output is the only thing that counts.

Software developer will effectively switch to thinking how to let somebody apply the program to produce output. In that way, all that lies below a very thin line under the user interface becomes the developer’s own problem, rather than being the customer’s problem. The customer will see none of the elements below the surface and they will forever remain the software developer’s domain of business.

Software as a Useful Tool

From a broader perspective, to develop a working software means to develop the inner parts in such way that outer parts, the user interface, can operate and let the user produce the desired output.

All business processes remain the duty of the software to perform. Software will not expect the user to navigate through processes and effectively run them manually. Instead, software will expect the user to fill in the required information so that the processes can be executed on their own.

If you were successful doing that, your software will not be a very fast pencil. It will turn the tables and do the right thing (whatever that is) to solve the problem for the user.

Summary

In this article, we have shed light on one of the most prominent issues in software development – the problem of understanding what customer needs, as opposed to accepting what the customer is asking for.

When we scratch under the surface, we find great uncertainty in customers’ views, which comes from misunderstanding the role of software, and the working principles of machines if you like.

Customers need guidance to the realm of software. Developers need to interview customers to understand the problem the business is solving, not just the current working principles of the business itself.

Once understanding of the problem is established, the duty of software developer is to produce abstract model of the problem and implement processes upon it. The result should be the software product, which is performing business processes in fully automated fashion, so that the user doesn’t have to perform them manually.

This article has been extracted from the Working Software series, episode zero. If you wish to learn more, please watch the entire episode and other episodes from the series online.

---