The UK and Germany got the same green

I ported a dashboard from a web service into a mobile app as a read-only screen. It shows participation by country as a donut chart.

Logic and values were verified against the server response byte for byte. Zero differences.

The defect that showed up on screen was not a number. It was a color.

Do you copy the original implementation, or rewrite it the way that looks simpler?

Hashes collide

Each country's slice color came from a hash of its country code. "Give every code its own automatic color" sounds reasonable.

Rendered against live data, the UK and Germany came out the same green.

The palette has six colors. When hashes collide, you get the same color, and the legend no longer tells you which country is which.

6-color palette + hash indexing -> collisions depend on the codes
6-color palette + rank indexing -> collisions impossible within a screen

The original web service never had this problem, because it indexed the palette by rank, not by hash. Color follows "how large is this country in this view," so within one screen a collision cannot occur.

I rewrote it the simpler-looking way and recreated a problem the original had already avoided.

Two more of the same shape

• The chart library's "draw a reasonable number of ticks" option is ignored on a categorical axis. All fourteen country labels rendered on top of each other. I had to stop trusting the default and pass the ticks explicitly.
• Copy lifted from the web ended up saying the same thing as the tile right next to it. A label meaning "items created today" was indistinguishable from a neighbouring tile meaning "users who joined today."

The third one is the interesting one. On the web that ambiguity never surfaced because that neighbouring tile did not exist there. Not a character of the copy changed; the new context made it wrong.

Here is where it splits

How do you verify a ported screen? The Android release build hides this screen behind a login gate, so I could not look at it directly.

Would you drop release-build verification, or substitute indirect evidence?

I substituted. I checked that the relevant strings and classes survive in the obfuscated build, and that crashes were zero.

But it matters to write down exactly what that proves. I inspected light and dark modes by eye in the debug build; for the release build I confirmed "it did not break," not "it looks right."

Self-check

• Are you assigning colors or order by hash? With more items than palette entries, collision is a matter of time.
• Did you check why the original was written that way, or rewrite it because it looked simpler?
• Does ported copy say the same thing as its new neighbour?

The honest part

Numbers were compared across six scalars, twelve per-country fields, four time series, and every field of the top list: zero difference. The numbers were right from the start.

The only wrong step was the last one, turning those numbers into colors. Most of the time I spent verifying accuracy went past the place that was actually wrong.

In a screen you ported recently, pick one part you wrote differently from the original and write down why.