The Fat Finger Principle
I would like to propose a new software development principle, to be enshrined alongside other fan-favourites such as the Single Responsibility Principle (SRP) and the Principle of Least Astonishment (POLA). It goes as follows,
The Fat Finger Principle (FFP)
Assume that all user-supplied input and data is erroneous and will require modification in the future.
The FFP is not talking about validation of user input or the sanitization of data. Rather, it applies to data which a computer system considers as being valid. The actual content, however, is inaccurate or incorrect.
The principle is inspired from a concept which exists in securities trading called Fat Finger Errors. An example of a Fat Finger Error is when a trader mistakenly inputs an extra zero on a buy order only to buy a number of securities ten times the amount they intended.
To err is human; to forgive, divine
The Fat Finger Principle is necessary because humans, by nature, are not infallible. We, as humans, frequently make mistakes or change our mind. It is therefore our responsibility, as software developers and architects, to design systems that account for such possibilities. We must ensure that any user input can be easily modified or undone.
Regrettably, designing such systems does not come naturally to software developers because they themselves seldom use the systems they build. I often see systems that are excellent at doing what the developer expected their users to do… but all hell breaks loose as soon as a user would like to change their surname, for example, after they get married.
The FFP in practice
One of the best examples I found of a system which correctly implements the FFP is Google’s Gmail product. The web application will confirm every action that a user performs, offering them the option to Undo their previous action. Amazingly, it does this also when sending an e-mail! The application will allow the user to cancel sending an e-mail, for a few seconds, if they somehow accidentally click on the send button.
When designing your components make sure you truly consider every aspect of your domain objects. A good technique which I find helpful is to sit down and come up with the most ridiculous scenarios that could cause input data to change. Think about how a customer support agent, who’s working from home, could have their pet cat walk across their keyboard as they are on a live chat with a client. Then, design accordingly.
Even if the situations you come up with do not ever happen in practice, you will be forcing yourself to fully model the domain within which you’re working. To convince yourself of the importance of this exercise, look out for occasions around you where you could have really used an Undo button. You will be surprised at how often you’ll encounter such situations.
MVP vs FFP
You will inevitably run into the argument that such functionality is not needed, that users “should not” ever need to change their input and that we should implement such functionality only when it is needed. Indeed it looks like the FFP goes against the spirit of designing the Minimum Viable Product (ie. MVP).
Keep in mind, however, that the FFP does not call for additional features but rather it asks developers to go the extra mile. Development teams should not add in any additional useless features to a system; they should, however, think how modifications can be applied in the features they do need. By forgoing this responsibility they could be unintentionally causing “technical debt” that will have to be fixed, in the future. Remember that the aforementioned extra mile will be an insignificant amount of time compared to the time spent fixing technical debt that will be required.
By adhering to the FFP, you will notice that the systems you develop will naturally feel more complete and more reliable even outside of instances where a human error occurs. Your system will have less “hacks” and workarounds. Your system will anticipate the worst that humans can throw at it — and rest assured, they will!
Acknowledgements
I would like to thank my colleagues, Francesco Borg Bonaci and Benjie Gatt, who helped me come up with the name for the principle and also helped me more clearly formulate the concepts explained within.
Kyle is a software developer, based in the sunny island of Malta, with experience in financial and betting systems. You can see Kyle’s work on GitHub.
