DEV Community: Shambhavi Chavan

# Fewer Steps, Fairer Shifts: Optimizing Warehouse Order Picking with Capacity-Aware Assignment and Open-Path Routing

Shambhavi Chavan — Mon, 12 Oct 2026 11:17:59 +0000

How a small, testable pipeline — fair work assignment, shortest-route planning and a live 2D map — attacks the single biggest waste in a warehouse: walking.

1. The problem: a picker's steps are the most expensive resource

Meet Hannah, a warehouse picker. Every shift she walks the length of a long-distance race leg — roughly 12–15 km, about 18,000 steps — and a third of her day is spent on foot. Most of that distance is wasted backtracking between the same aisles.

The consequences are familiar to anyone who has worked on a warehouse floor:

Sore feet and fatigue by mid-shift
Constant pressure to hit pick quotas
Confusion over "what do I grab next?"
Uneven workloads — some pickers slammed, others idle

The hidden cost is large. Unoptimized routes that simply follow the order in which tickets were printed add an estimated 30–50 % of avoidable walking to every pick round, and walking takes up around half of a picker's time — the single largest slice of the shift. Fatigue then feeds back into more mis-picks and more safety incidents.

2. Why the problem persists

Three gaps keep the floor slow and unfair:

Walking in ticket order. Pickers follow the order the tickets were printed in, not the smartest path through the racks.
No load balancing. There is no capacity-aware way to spread work, so some workers drown while others wait.
No shared map. Planners cannot see or explain the plan — there is no single picture of the floor.

Stated this plainly, the solution space becomes obvious: optimize who picks what, optimize the order in which they walk, and make the result visible.

3. The approach: PickPath

PickPath is a prototype built around those two levers — assignment and routing — plus a visualization layer that makes the plan obvious to both pickers and planners. It deliberately focuses on picking only, leaving put-away, replenishment and packing out of scope.

Goal	What it means
Less walking	The shortest feasible route for every worker, every round
Fair loads	Work balanced across workers under a hard per-zone capacity
Full visibility	One live, shared 2D map of the floor and every route

4. Architecture: a four-stage pipeline

PickPath processes a scenario end to end in four stages:

Input — Load. The warehouse layout and the pick tickets are loaded from portable CSV or JSON scenario files.
Assign — Balance. Tickets are grouped by zone and balanced across workers under capacity. Anything that does not fit is queued for the next round — nothing is dropped.
Route — Optimize. For each worker, the engine computes the shortest path: printer → all assigned bins → exit.
Visualize — Animate. A cart walks each route on a 2D map, and a QR scan confirms every bin before the next stop is unlocked.

The reference scenario used throughout development contains 96 racks/bins, 6 workers (2 per zone) and 24 tickets across three zones (A, B and C) with different capacities.

5. Engine 1 — Fair, capacity-aware assignment

The rules

Zone capacity is a hard cap per worker per round. In the reference scenario Zone A allows 5 picks, Zone B 20 and Zone C 80.
Greedy / LPT balancing. Each ticket goes to the least-loaded eligible worker (the classic Longest Processing Time first heuristic for load balancing).
Overflow, never drop. If the best worker is already at capacity for the current round, the ticket is queued into that worker's next round.
Pluggable. The heuristic sits behind an interface so it can later be replaced by an exact solver (Integer Linear Programming or min-cost flow).

The algorithm

Tickets are first bucketed by (zone, task type). Within each bucket the engine repeatedly hands the next ticket to the least-loaded eligible worker:

for ticket in bucket:
    best = min(eligible, key=lambda w: load[w])
    if in_round[best] >= cap:
        round[best] += 1          # overflow to the next round
        in_round[best] = 0
    assign(ticket, best)          # never drop a ticket
    load[best] += ticket.size
    in_round[best] += 1

In the reference run, the two Zone B workers end up with exactly 12 / 20 picks each — perfectly balanced and well under the cap.

What the tests prove

Unit tests assert two invariants on every run: no worker ever exceeds their zone capacity, and every ticket is either assigned or explicitly queued — no ticket silently disappears.

6. Engine 2 — Shortest route on a real aisle graph

Modelling the route

Each worker's round is an open-path Travelling Salesman Problem (TSP) with fixed endpoints: the path must start at the label printer, visit every assigned bin exactly once, and end at the exit. Unlike the classic closed-tour TSP, the worker does not return to the start.

Distances that respect the floor

Straight-line (Euclidean) distance is meaningless in a warehouse — a picker cannot walk through a rack. PickPath therefore models the floor as an orthogonal aisle graph: nodes sit on walkable lanes, edges run along aisles, and cross-aisles connect them only where there are gaps between racks. Shortest-path distances between every pair of points of interest (printer, bins, exit) are pre-computed on that graph and fed to the route optimizer as a distance matrix.

Nearest-neighbour seed + 2-opt

The optimizer uses two well-known, fast heuristics:

Nearest-neighbour seed. Starting at the printer, repeatedly walk to the closest unvisited bin, then finish at the exit.
2-opt local search. Repeatedly take a segment of the route and reverse it whenever doing so shortens the total path. Because the endpoints are fixed, only the interior of the route is ever reversed.

def two_opt(route, dist):
    # route = [printer, bin_1, ..., bin_n, exit]; endpoints stay fixed
    improved = True
    while improved:
        improved = False
        for i in range(1, len(route) - 2):
            for j in range(i + 1, len(route) - 1):
                a, b = route[i - 1], route[i]
                c, d = route[j], route[j + 1]
                if dist[a][c] + dist[b][d] < dist[a][b] + dist[c][d]:
                    route[i:j + 1] = reversed(route[i:j + 1])
                    improved = True
    return route

The guarantee

Because 2-opt only ever accepts improving moves, the optimized route can never be longer than its starting point. PickPath additionally checks the result against the naive ticket-order route and enforces in its test suite that optimized distance ≤ naive ticket-order distance — always. The visual difference is striking: the naive route is full of backtracking and crossings, while the optimized one flows along the lanes.

7. Making the plan visible: the live 2D simulation

Optimization that nobody can see is hard to trust. PickPath renders the warehouse top-down — zones, racks, printer and exit on one shared map — and animates each round:

A cart moves along the route from the printer through every bin to the exit.
It dwells at each pick with a status such as "Picking B2-4 · 3/8".
A navigation-style panel gives turn-by-turn directions and a timeline.
Play, pause, speed control and timeline scrubbing let planners replay any round.

Scan to advance

At each stop the worker scans the bin's QR code. A wrong scan blocks the next stop, so the worker physically cannot move on with the wrong item — a simple, effective guard against mis-picks.

8. Results

The headline results below are enforced by the automated test suite, not just claimed:

Metric	Result
Route quality	2-opt distance ≤ naive ticket-order distance, always
Ticket coverage	100 % of tickets assigned or explicitly queued
Capacity violations	0 — no worker exceeds their zone cap
Automated tests	15, all green in CI on every push
Routing time	< 1 s for the 24-ticket scenario
Pick verification	100 % of picks QR-verified; wrong bin blocked

Total walking distance is printed per worker for every run, so the improvement is measurable rather than anecdotal.

Projected operational impact

The following figures are projections derived from the measured route and assignment gains, not measurements from a live deployment:

Dimension	Projected impact
Time	30–50 % less walking per round; +15–25 % more picks per hour from reclaimed walking time
Cost	~20 % lower pick-labour cost per order line; ~2 hours of walking saved per picker per shift
Human error	~30 % fewer fatigue-driven mis-picks; zero overloaded workers
Coordination	Manual dispatch replaced by one shared, explainable plan

9. Engineering for production, not just for the demo

A hackathon prototype is only useful if it can grow. PickPath was built with that in mind:

Containerized with Docker for repeatable runs.
PostgreSQL for persistence, with an SQLite fallback for zero-setup local use.
Portable JSON scenarios, so new layouts and ticket sets can be tested without code changes.
Secure by default: non-root container images, no hard-coded secrets, and validated inputs at every boundary.

10. Roadmap

The tested foundation is ready for a pilot. The next steps are:

Smarter solver. Swap the greedy heuristic for an ILP or min-cost-flow optimizer behind the same interface, and compare results on the same scenarios.
Live order streams. Ingest real ticket streams from a warehouse management system and re-route dynamically as new orders arrive.
KPI dashboard. Track distance saved and workload fairness over time, per worker and per zone.

11. Key takeaways

In order picking, walking is the dominant cost — optimizing it pays off more than almost anything else on the floor.
Two classic, well-understood techniques — LPT-style greedy balancing and nearest-neighbour + 2-opt routing — deliver most of the gain at sub-second speed.
Model the real floor. Distances must follow aisles, not straight lines.
Encode the guarantees as tests: capacity is never exceeded, no ticket is dropped, and the optimized route is never worse than the naive one.
Make the plan visible. A live map and scan-to-advance turn an algorithm into something pickers and planners trust.

Smarter picking. Shorter walks. Fairer workloads.

Where Do Settings Live?

Shambhavi Chavan — Mon, 12 Oct 2026 10:37:57 +0000

Where Do Settings Live?

Designing User Preferences for a Multi-Region World

"I changed it yesterday. Why is it back?"

Every product team hears this sentence eventually. It usually arrives as a vague bug report, gets labelled "can't reproduce" and comes back three sprints later with a longer email thread attached. Behind it there's almost never a single broken line of code. Usually a team simply never answered one question:

Where does this setting live and who is allowed to change it?

This article is about answering that question on purpose, using a fictional but very realistic product, the bugs it ran into and the design rules that made those bugs go away for good.

Meet "Fieldbook"

Fieldbook is an imaginary web app used by service teams around the world. Technicians use it to look up jobs, estimate effort and export reports. It's used in dozens of countries, it's available in many languages and it runs both standalone and embedded inside a larger partner portal.

Users can personalise a few things:

Setting	Example values	Why it matters
Unit system	Metric / Imperial	Distances, weights, torque values
Effort scale	Hours / Work units	Some regions bill in standardised units, not hours
Report format	PDF / CSV / Legacy CSV	Downstream tools in each country expect different files
Remember my choices	On / Off	Whether any of the above should persist at all

Four settings. A form, a save button, a database table. Simple, right?

The Bugs

Within a few releases, the support inbox told a different story:

Settings overwrote each other. Changing the effort scale quietly reset the report format. Each screen loaded the whole preferences object, changed one field and wrote everything back, including stale values.
Settings were wrong after switching regions. A technician working at sites in two countries had to re-pick his effort scale every time he switched. One value was stored per user, but the setting really depended on the user in a region.
Settings couldn't be changed, with no explanation. In embedded mode, the partner portal passed a required value through the URL. The user could still edit the dropdown, the change was ignored on the next load and it then leaked into standalone mode.
"Remember my choices" didn't remember. Turning persistence back on saved nothing until some other setting changed, because saves only fired on individual change events.
The app wouldn't start. Loading preferences was part of startup and the app waited for it. When the preferences service was slow inside the embedded frame, users got a blank screen.

Five different symptoms, but the same root cause behind all of them: nobody had defined the scope, source and authority of each setting.

The Three Questions Every Setting Must Answer

For every preference you add, write down the answers to these:

Scope: Whose setting is it? The user's, the user's within a region, the device's, or the organisation's?
Source: Where can the value come from? A saved preference, a URL parameter, a host application, a regional default, a hard-coded fallback?
Authority: Who wins when two sources disagree?

If you can't answer all three, you haven't designed the setting yet. You've only built a checkbox.

The Fixes: Five Design Rules

1. A save touches only what the user changed

Replace read-modify-write of the whole object with partial updates and keep unrelated settings from sharing a save action.

// Before: overwrites every field with whatever this screen loaded earlier
await api.put('/preferences', { ...current, effortScale: 'hours' });

// After: send only the delta
await api.patch('/preferences', { effortScale: 'hours' });

2. Model the real scope

If a setting varies by region, the region belongs in the key:

{
  "userId": "u-456",
  "global":   { "unitSystem": "metric" },
  "byRegion": {
    "DE": { "effortScale": "units", "reportFormat": "csv" },
    "AT": { "effortScale": "hours", "reportFormat": "pdf" }
  }
}

If the setting depends on…	Scope it to…	Example
Personal taste	User (global)	Dark mode, language
Local business rules	User × Region	Billing scale, report format
The physical device	Device (local storage)	Panel sizes, last-opened tab
Company policy	Organisation	Allowed export types

3. Separate the value from its source

Resolve every setting through clear layers and remember which layer won:

┌──────────────────────────────────────┐
│ 1. Locked by host / URL  (read-only) │  ← highest authority
├──────────────────────────────────────┤
│ 2. Saved user × region preference    │
├──────────────────────────────────────┤
│ 3. Saved user (global) preference    │
├──────────────────────────────────────┤
│ 4. Regional default                  │
├──────────────────────────────────────┤
│ 5. Application default               │  ← always present
└──────────────────────────────────────┘

If the value came from a lock, show the control disabled with a short explanation ("Set by your organisation's portal") and never persist it as if the user chose it. When the lock goes away, the user's own choice comes back untouched.

4. Treat persistence toggles as state machines

Transition	Action
Off → On	Persist the current effective values immediately
On → Off	Stop writing and decide on purpose whether to keep or clear stored values
On → On (any change)	Patch only the changed field (Rule 1)

Put the toggle behind a feature flag so you can roll it out gradually and switch it off without a redeploy.

5. Preferences enhance the app. They never block it.

Render immediately with defaults, apply saved values when they arrive and time-box the request.

initialize() {
  this.preferences.set(defaultsFor(this.region));            // render immediately
  this.api.getPreferences().pipe(timeout(3000)).subscribe({
    next: saved => this.preferences.set(merge(defaultsFor(this.region), saved)),
    error: ()    => this.log.warn('Preferences unavailable, using defaults'),
  });
}

Don't Forget the Humans

Translate the explanations, not only the labels. A "Set by your organisation" tooltip only helps if it's in the user's language. Ship every new string (label, help text, locked-state message, release note) to every supported locale in the same change.

Tell users what changed. A one-line release note like "Your settings are now saved separately for each region you work in" prevents a wave of "why is it different now?" tickets.

Testing the Gaps

Settings bugs live between features, so test those gaps directly:

Concurrency: save A, then save B from a stale state. A survives.
Scope: save in region X, switch to Y, switch back. X is intact.
Authority: load with a locked URL value. The control is disabled and nothing is persisted.
Transitions: toggle persistence off → on. Effective values are saved.
Resilience: fail or time out the preferences service. The app still renders.

Closing Thought

User preferences look like the most boring part of an application. In a product used across regions, languages and host platforms, they turn out to be a small distributed system with scopes, sources, authorities and failure modes.

So the next time someone says "I changed it yesterday, why is it back?", don't start with the code. Start with the question:

Where does this setting live and who is allowed to change it?

If you've fought your own "it reset itself" battles, I'd love to hear how you solved them.