When working on MacOS 8.x (not sure which point release), they surveyed users, and their number one complaint was boot time. It took long for the system to boot (around 45s on average at the time). They looked into it but also asked the question, why do people care about boot times at all? At this point, the systems were capable of sleeping, so reboots should be rare.
They found that people were rebooting because of instability, not just once a day or once a week. While they did improve the boot times, they put more effort into making the OS more stable. When the new release shipped, people stopped complaining about boot time, but not because it was vastly improved, instead because they were doing it less often.
The moral of the story is to make sure you understand both what your customers are asking for and why your customers are asking for it.
> When working on MacOS 8.x (not sure which point release), they surveyed users […] They found that people were rebooting because of instability, not just once a day or once a week.
That didn’t require a survey. The OS didn’t have memory protection and typically got patched at startup by ten or so different extensions from both Apple and numerous third parties.
The rules for patching were unclear, to say the least (1), so an extension might, for example, have a code path where it allocated memory inside a patch to a system call that might be moving memory around (a no-no, as the memory manager wasn’t reentrant)
And that had to run code that typically was compiled with a C compiler of the time, with very, very limited tools to prevent out of bounds memory writes.
Apple's customers had been screaming for better stability for years and Apple repeatedly tried and failed to deliver a meaningful solution. Even MacOS 8 introduced very limited memory protection that didn't help much in most practical cases. In context, it's really a story about an organization's capacity and will to rationalize - this very nearly killed Apple as a business.
> In context, it's really a story about an organization's capacity and will to rationalize - this very nearly killed Apple as a business
What damaged Apple's Mac business in the 1990s might been due to tunnel vision and self-delusion, but the driving issue was a loss of obvious differentiation vs. cheaper PCs running Windows. They were all beige boxes with a serviceable GUI that ran the same software, and customers didn't see the value in paying Apple's premium prices.
With the return of Steve Jobs, Apple resolved the PC differentiation issue by refocusing on design in both hardware (iMac) and software (OS X); Apple also sidestepped Windows dominance by focusing on non-PC devices such as the iPod, iPhone, and iPad.
That certainly sounds about right. I definitely lost more time to the fact that a Quadra would freeze with high probability during a scan than I ever lost to intentional reboots.
When a friend first showed my wife Mac OS X and went to shut it down she frowned, "That's something I liked about the Mac, it would shut down instantly."
"You'll have to find something else to like about Mac OS," he said.
Well, most of the time it's not like you have to sit beside your (desktop) computer and wait until it has finished shutting down, so I guess that's less of an issue than the startup time...
It's an immutable law of the universe that consumer computers will always take at least 30-45 seconds to boot. If yours is faster, wait a few years... the developers will allow enough regressions to slip in that it'll go back up again.
Every time I’ve had a computer that would boot faster than that, it seems I’d be stuck with a monitor that would take 30 seconds to come on and decide to display something.
By the time Mac OS 8.0 was released in 1997, Macs all had MMUs and Apple was already working on merging Mac OS and NeXTSTEP; the first iteration was released in 1998 as Rhapsody.
If I remember right, in "The Inmates are Running the Asylum", Alan Cooper says there are two golden rules:
* The user is always right.
* The user is not always right.
And then the explains the first point is that the user should be treated as the authority on what their problem is. You can't just tell them they're "doing it wrong" or rationalize away their pain.
The second point is that users are not designers and shouldn't have to be. They'll often come up with ideas for solutions, but you shouldn't take those as what needs to be done.
The first point is really common in programming. If you ask a "stupid" question, you don't get an answer like "here's how to do it, but by the way, you could also do this instead" but just flame you with "you shouldn't have been doing X".
Good example is FTP. Obviously, for anything requiring any kind of security, use SFTP. But I kid you not, almost all FTP-related questions on the internet have answers like "are you still using that INSECURE protocol in 2020??" without being constructive at all. Even if it's just some random hobby project. Or a legacy system they can't change. Doesn't matter, it's more important to score points from virtue-signaling than actually helping the poster.
Even if it's just some random hobby project. Or a legacy system they can't change.
Or a modern system.
My brand new image scanner only transfer files wirelessly via HTTP or FTP.
People in places like HN freak out with "Oh noes! Teh securities!" But its wireless connection is as a wifi access point that only allows one client to connect, and only stays active for a few minutes.
I like this, and I think it applies best to creative works, in which the creator is the expert on the characters and storytelling. (A screenwriter needs to know the audience isn't feeling the romantic chemistry between the two leads, but probably doesn't want to hear their steamy fanfic scenes.)
But when designing solutions for people who are the domain experts (and this might even just be the domain expert of how a particular factory line works in practice), the dialogue with them likely includes their ideas for solutions. These ideas don't have to be "right" as-is, but might suggest the right direction, or just be loaded with bits of relevant knowledge that inform whatever the solution ends up being.
Valid! But I think it still works. Because when you're designing software for domain experts, they know their domain, but they don't know yours (software design)
So yeah, they'll say why something won't work, but the solution will probably involve another button, another drop-down, a hamburger-menu, or another option in the settings.
And then it's your job to figure out if it's the right solution.
> The moral of the story is to make sure you understand both what your customers are asking for and why your customers are asking for it.
One reason engineers enjoy questioning the premise of a difficult feature is to avoid the work entirely. The problem with this is not that engineers are lazy its that the success metrics after the goal posts are moved can be futzed in a way that ultimately is detrimental to users.
Did Apple really improve boot times and OS instabilities to a complete resolution or did an aspiring PM or Lead achieve the bare minimum of the goal to claim victory internally?
When working on MacOS 8.x (not sure which point release), they surveyed users, and their number one complaint was boot time. It took long for the system to boot (around 45s on average at the time). They looked into it but also asked the question, why do people care about boot times at all? At this point, the systems were capable of sleeping, so reboots should be rare.
They found that people were rebooting because of instability, not just once a day or once a week. While they did improve the boot times, they put more effort into making the OS more stable. When the new release shipped, people stopped complaining about boot time, but not because it was vastly improved, instead because they were doing it less often.
The moral of the story is to make sure you understand both what your customers are asking for and why your customers are asking for it.