What are your opinions of fudgeability in software design?

twitter logo github logo 惻1 min read

Alan Cooper writes in "About Face":

The characteristics of manual systems that lets humans perform actions out of sequence or before prerequisites are satisfied is called fudgeability.

One example he mentions is "a transaction that can only complete if the termination date is extended two weeks beyond the official limit. Most companies would rather fudge on the termination date than to see a million dollar deal go up in smoke'

What do you think about software systems being "fudgeable"?

On the one hand I think it can improve the user experience quite a bit, on the other hand we finally have some systems in place that force people to play by the rules and this would make them as bad as the manual version.

twitter logo DISCUSS (4)
markdown guide

Victor makes a good point. I would also throw in that context matters. Sometimes the rules are in place because someone in management has declared "thou shalt do it my way" with no understanding of the actual process. Sometimes the rules are in place because somebody made the date value required in the database so therefore a date must be entered before you can continue even if that date isn't actually necessary. And sometimes you really shouldn't make that withdrawal from that bank account if the balance is 0.


Fudgeability empowers the user with great flexibility. But with powers comes responsibility, which is something that the users don't always realize.

I have seen systems where the flexibility (fudginess?) have been so great that the users ends up breaking the system and some technical staff needs to step in and put things in place.

As with most things in life there must be some sort of balance.


I've been working on a few applications lately that are highly fudgeable. The common theme across all of them is that no-one on the product teams actually understands the real use cases and business rules their users need to adhere to.

As a result, instead of writing rigid and predictable business logic, the teams have opted to let almost anything happen at any time. Leading to an incredible overhead in training their users in what not to do with their system. Failure to adhere to this training can take down the entire application with the click of a few buttons. The best part of this is that given the infinite number of ways that things can be done in these applications, even the teams themselves don't know every combination of clicks and key-presses that can cause catastrophic issues with the application.

Overall, my feeling is that if a system needs to be fudgeable, it's suffering from poor design. If there exists a business rule in an application that folks are consistently working around, then it's not a valid business rule at all and should probably be removed.



I can understand that most software is rather rigid and people are used to their own workflow, which doesn't work with their software.

Sometimes the question is: was the old workflow really good?

Some people don't want to switch to another workflow, even if its superior.

Sometimes it is: were their any rules in place that can't be ignored?

There are laws to obey or business rules the management set in place to move the behavior in a certain direction.

Classic DEV Post from Oct 1 '18

I created a bot that talks to recruiters for me (and it's sooo good!)

My name is Kevin, and Iā€™d like to tell you a story about an easy way I stopped recruiter spam using one bot.

K profile image
Author, Educator and Software Consultant

Hey there reader...

Do you prefer sans serif over serif?

You can change your font preferences in the "misc" section of your settings. ā¤ļø