FizzBuzz Extension • Coding Kata
FizzBuzz has a strange reputation. On one hand, it’s dismissed as a joke. On the other, it keeps showing up in interviews, blog posts, and practice exercises. The problem isn’t FizzBuzz itself — it’s how it’s usually used.
This post explains how I’ve been using FizzBuzz as a real coding kata: one that starts simple, then gradually applies pressure through carefully chosen follow‑up requirements.
What is a coding kata?
As described in a previoppus blog post, a coding kata is a small, repeatable programming exercise designed for practice rather than delivery.
The goal isn’t to solve a hard problem. The goal is to work through a familiar problem so you can focus on how you write code:
clarity over cleverness
naming and structure
trade-offs under change
refactoring without fear
The best katas are intentionally simple. That’s what makes them effective.
The base FizzBuzz kata
The starting point is intentionally minimal:
a fixed range (1–100)
three simple rules (Fizz, Buzz, FizzBuzz)
clear, readable output
no optimisation, no UI, no guessing future requirements
The goal here is not extensibility. It’s correctness and clarity today.
That distinction matters.
Check out my previous article for the "why" of the base FizzBuzz kata.
Adding pressure with follow-up requirements
The real value comes from what happens next.
Instead of asking for a “better” or “more extensible” solution up front, I introduce additional requirement sets, one at a time. Each set adds just enough change to stress the original design.
Examples of what these follow-ups explore:
removing hard-coded assumptions
adding new rules
changing rule ordering
introducing new output formats
filtering results
handling stateful or lookahead behaviour
Crucially, the requirements stay behavioural. They describe what the program must do, not how it should be implemented.
After each step, the most valuable part isn’t the code — it’s the discussion:
What broke?
What was easy?
What assumptions did we make early?
What would we do differently next time?
Why this approach works
This setup avoids two common traps:
Over-engineering up front
You’re not designing for imaginary futures. You’re responding to real, concrete change.Toy problems with no depth
Each follow-up requirement exposes a different axis of design pressure.
By keeping requirements small and explicit, you get a clear signal about code quality without turning the exercise into a framework-building contest.
How I run this kata
My usual flow looks like this:
Implement the base FizzBuzz requirements.
Draw one follow-up requirement set at random.
Implement only what’s required.
Pause and review.
Repeat if needed.
This works well solo, in interviews, or with teams. It scales from junior developers to very experienced ones — the discussion just changes shape.
Final thoughts
FizzBuzz doesn’t need to be clever to be useful.
With the right constraints and follow-up requirements, it becomes a sharp tool for exploring design, refactoring, and trade-offs under change. And because everyone already understands the problem, all the attention goes where it should: on the code.
Follow-up Requirement Sets
FizzBuzz – Additional Requirements Set 1: Configurable Range
Additional Requirements
The program must allow the start and end of the number range to be provided as inputs, instead of being fixed at
1–100.The program must support running the logic for multiple ranges in a single execution, producing separate outputs for each range.
FizzBuzz – Additional Requirements Set 2: New Rule (Seven)
Additional Requirements
If a number is divisible by
7, the output must include the word "Bang".When the number is divisuble by
7, any other values (eg, "Fizz") should be replaced by "Bang", so the input put21should return "BangBang", since it is divisible by both7and3
FizzBuzz – Additional Requirements Set 3: Runtime Rule Ordering
Additional Requirements
The program must allow the order of rule outputs (e.g.
Fizz,Buzz,Bang) to be specified at runtime.Changing the rule order must affect only the ordering of words in the output, not which rules apply.
By default, ordering should be applied by alphabetical order of the output words (eg,
Fizzcomes afterBuzz).
FizzBuzz – Additional Requirements Set 4: CSV Output Option
Additional Requirements
In addition to console output, the program must support producing the full result set in CSV format, with a flag used to select the output.
In CSV output, each line must contain two values: the number and the corresponding output (e.g.
15,FizzBuzz).
FizzBuzz – Additional Requirements Set 5: Skipping Values
Additional Requirements
The program must accept a list of numbers to skip, which must not appear in the output.
The program must accept a list of output values to skip; if an output contains any skipped value, that line must be omitted.
FizzBuzz – Additional Requirements Set 6: Lookahead Rule
Additional Requirements
The program must support adding new rules in addition to the existing ones.
If the next value in the range would produce "Fizz", the current output must also include the word "Ramp".
FizzBuzz Kata – Follow-up Requirements Summary
Don't read this until you have completed your exercise.
This section describes the intent behind each additional requirement set used with the FizzBuzz kata. The goal is not to prescribe an implementation, but to surface design trade-offs and prompt discussion.
Set 1: Configurable Range
What this set explores
Removal of hard-coded assumptions
Handling repeated executions cleanly
Whether core logic is reusable or tightly coupled to a single run
Set 2: New Rule – Seven
What this set explores
Introducing new behaviour
Generalisation beyond the original rules
Cost of adding incremental requirements
Set 3: Runtime Rule Ordering
What this set explores
Separation between rule definition and application
Hidden assumptions about ordering
Flexibility under non-functional change
Set 4: CSV Output Option
What this set explores
Separation of computation and presentation
Impact of output format changes
IO coupling
Set 5: Skipping Values
What this set explores
Filtering logic
Composition of rules
Control-flow clarity
Set 6: Lookahead Rule
What this set explores
Stateful behaviour
Cross-item dependencies
Refactoring under pressure
How to Use These Sets
Start with the base FizzBuzz requirements.
Apply one additional requirement set at random.
Implement only what is required.
Review before drawing the next set.
The discussion is usually more valuable than the final code.