Hick’s Law: Why Fewer Choices Lead to Better Software and Faster Teams
W.E. Hick and R. Hyman conducted experiments in the 1950s and found something counterintuitive: the time it takes a person to make a decision grows logarithmically with the number of options. Double the number of choices, and decision time increases, but not by double. The relationship is logarithmic. More choices always mean slower decisions, even when the additional choices are good ones.
For software teams, this is true in at least three distinct dimensions: what you build, how you build it, and how the team operates. Most teams experience Hick’s Law daily without naming it.
What You Build: Complexity Is a Choice
Every feature you add to a product is an option you’re presenting to the user. More features mean more time for users to find what they need. More configuration options mean more time deciding how to configure. More menu items mean slower navigation.
This is a design problem with a LEAN solution: eliminate everything that doesn’t deliver clear value. The LEAN principle of eliminating waste applies directly to feature scope. A feature nobody uses is waste. A configuration option nobody changes is waste. A menu item that exists for historical reasons and confuses new users is waste.
Minimum viable products exist partly for this reason. The MVP constraint forces teams to identify the smallest feature set that delivers real value. That constraint, applied well, produces software that’s faster to build, easier to use, and simpler to maintain. The simplicity isn’t accidental. It’s designed.
How You Build It: Convention Over Configuration
Inside software teams, Hick’s Law shows up in technical decision-making. When a team starts a new service and has to choose a framework, a testing library, an ORM, a logging approach, and a deployment strategy from scratch, the decision cost is real and often invisible. Engineers spend time evaluating options instead of building things. Different services end up with different choices. The cognitive load of context-switching between them accumulates.
Convention over configuration is a direct application of Hick’s Law. If the team has agreed that new services use a specific framework, a specific pattern for logging, and a specific deployment pipeline, that’s decision time eliminated. Engineers can focus on the problem they’re solving instead of relitigating choices that have already been made.
Agile frameworks do this at the process level. Scrum provides specific ceremonies, roles, and artifacts. Teams that follow the framework don’t spend time figuring out how to structure their work. The structure is given, and they apply it. The value isn’t that the framework is optimal in every case. The value is that the overhead of designing a process is eliminated.
On-Call and Incident Response
Hick’s Law applies with particular force in high-stress situations. During an incident, when something is broken in production and every minute of downtime has a cost, the number of decisions a responder has to make determines how quickly they can act.
Runbooks that present a single clear action path at each step are faster to follow than runbooks that present multiple options and leave the responder to evaluate them. Decision trees with clearly labeled branches reduce time-to-resolution. Alerts that point to a specific potential cause rather than a general system component give responders a starting point instead of a puzzle.
LEAN’s single-piece flow concept applies here. Focus on one diagnostic path at a time. Eliminate options that aren’t immediately relevant. Get to resolution faster.
Backlog Management
Hick’s Law in sprint planning manifests as backlog overload. A product backlog with 400 items is not 400 ready-to-work opportunities. It’s a cognitive load problem. Every sprint planning session requires filtering 400 items to find the ones that matter this sprint. That filtering takes time and introduces risk of missing something important.
LEAN’s approach to this is continuous backlog refinement and aggressive pruning. Items that haven’t been touched in several sprints should be deleted or archived, not carried indefinitely. The backlog should contain only items the team is likely to work on in the foreseeable future. A short backlog is faster to plan from and easier to keep current.
Continuous Delivery practices contribute here too. When teams deploy frequently and can release small changes quickly, the cost of not building something is lower. There’s less pressure to add every feature defensively because the pipeline for adding things later is fast and reliable.
What to Apply Today
Audit your team’s conventions. Do you have agreed defaults for new services, or does every project start with a framework debate? If the latter, pick some defaults and document them. They can always be changed later with deliberate discussion.
Review your last sprint planning session. How long did backlog review take? If it took more than 20 minutes to identify the sprint’s priorities, the backlog needs trimming.
Apply this to whatever you’re building. Remove one configuration option that nobody changes. Delete one feature that analytics shows nobody uses. Measure whether anyone notices.
Fewer choices, made more deliberately, produce faster decisions and simpler systems.
Want to build software that moves faster by staying simpler? Let’s talk.