[userbinator]

Perhaps the limit was "available memory"? It's not hard to imagine how a programmer who has only ever worked with dynamic languages and basically doesn't know what a fixed-length-buffer is could be completely oblivious to it.

Then again, what is an appropriate limit on the length of the name of a HomeKit device? I'm tempted to say 255, but I'm sure someone else would disagree. I've been in design meetings where such things were discussed, with lots of bikeshed, so it's also understandable that, with deadlines and other priorities, they decided not to impose any limit.

[sodality2]

I can't imagine anyone would disagree with 1024 characters.

[userbinator]

"But that doesn't fit in a byte; why not make it 64k instead so it's 2 bytes?"

"Why not 1023?"

"Even 1023 is too long, I don't think anyone would need that."

"What if <long and convoluted use-case>?"

"How about 32?"

Having been in a few meetings that went in that direction, I am not surprised that they couldn't agree on a limit. "Design by committee" at its worst.

[sebastien_b]

I doubt it even went that far - given the size the story mentions (500,000 characters, but isn't clear if they tried smaller), my thinking is the programmer didn't make any checks whatsoever and just thought "no one will type in crazy-large values here, and even if they do it'll just truncate on display" (if that) without consideration on how it might affect memory.

[prox]

Another team that didn’t read nor adapted practices from About Face : on interaction design. What the team wants is irrelevant, how the user will adopt it is important, and for that you need to actually do tests.