[ozzythecat]

I don’t quite understand this comment.

As a customer, I don’t care what a firmware is or if it’s the best software or if it runs in Azure or iCloud. To me, it just works. I don’t care how. The fact that it works way better than competitor products I tried over the years is enough to say it’s well defined.

The key is a frictionless experience.

[jessriedel]

The topic of discussion isn't product performance, it's design. If a certain car model has a high top speed, this may be suggestive evidence that the engine is well designed, but the top speed itself is not considered an example good design. So it would be fine if we had something to say about the design of the Apple software that produced the reliable Bluetooth connection, but just the fact that something doesn't break isn't good design.

That's my understanding anyway.

[ozzythecat]

> If a certain car model has a high top speed, this may be suggestive evidence that the engine is well designed, but the top speed itself is not considered an example good design.

I don’t think this is a useful analogy. Top speed is a randomly picked metric, which presumably most car buyers don’t care for.

Once you get into the exotic super car car segment, then one could say that a super car that only tops out at 60mph or is 0-60 in 8 seconds is poorly designed… and more so if they care about performance over other measures (reliability, crash safety, fuel efficiency, comfort, etc).

A design document has both functional and non functional requirements.

> but just the fact that something doesn't break isn't good design.

If your non functional requirements optimize for reliability and consistency, and that’s exactly what your implementation does while making reasonable trade offs, that’s the exact hallmark of not just a good but great design.

[jessriedel]

> I don’t think this is a useful analogy. Top speed is a randomly picked metric, which presumably most car buyers don’t care for.

My comment applies to any metric that is an unalloyed good, not just top speed. Saying "AWS has high up-time" or "This car rarely needs repairs" or "I never spill coffee with this cup" are suggestive that something has been designed well, but they are not themselves substantive comments about the design. For that you'd have to say how they achieved those things. It's the difference between a goal and the method.

> that’s the exact hallmark of not just a good but great design.

Talking about trade-offs between goals would be substantive discussion of design. That one metric got high marks without saying anything about how is not.

I don't think this digression into semantics has reached diminishing returns.