True, but if everyone did that, there wouldn’t be any Apple engineers left to fix the damn software itself, because they’d all be running 24/7 support for millions of angry users, answering the same damn questions and complaints again and again and again.
If that is their intended process, then it is such a false economy that it warrants firings all the way up to the board.
This is why we write documentation—good documentation, that explains the product and how to use it, and anticipates the common problems that users run into and guides them through those as well. So that users can handle the day-to-day stuff and only need to interrupt its developers for the exceptional cases that no-one has anticipated—which is as much about the developers learning what more they need to fix as about getting users over that hump in the meantime.
.
Apple is absolutely, notoriously, abominable at documentation, in part I think because Apple really absolutely hates to admit that its shit ever smells too. But if you can’t own your own mistakes, then you’re never going to fix them and get rid of that stink.
Honestly, I really miss their old NeXt-derived docs from back in the early days of OS X, both in their content and their presentation and navigability. I mean, they weren’t brilliant—good on the Whats but not asogreat on the Hows—but compared to the slop they’ve been serving users these last 10 years those docs were an absolute masterclass. Or even look at Microsoft, who * and* accept their APIs are complex and difficult, and so document the tar out of them so their users can mostly get by for themselves.
.
The other problem is, the health of the developer platform today isn’t immediately, directly reflected in the size of the next quarter’s results. So when the company’s run by and for the beancounters and shareholders, without regard for what the engineers are telling them, they don’t see the need for greater long-term investment. I mean: everything works great now, just look at the size of those revenues!
It not till years later that the knockon effects of those poor upstream processes and resources reach the surface, at which point the damage is far more severe than it ever should have been had they nipped it at the start. Just ask the formerly engineer-led Boeing how that whole McDonnell-Douglas pennycounting culture is working out for them now. Yup.
While I concede documentation has slipped greatly the last 20 years to an all time low, Apple did produced the Inside Macintosh series, possibly the greatest developer documentation ever written.
IM was a work of art in its own right. Maybe a bit James Joyce, but if nothing else you could always mount it on your wall.
I spent a lot of time in the IAC book many moons ago, extracting the concepts and motivations left unspoken in Apple’s newer “long lists of buttons” documentation. “How” stuff makes vastly more sense once you understand the “Why” that underpins it all.
If that is their intended process, then it is such a false economy that it warrants firings all the way up to the board.
This is why we write documentation—good documentation, that explains the product and how to use it, and anticipates the common problems that users run into and guides them through those as well. So that users can handle the day-to-day stuff and only need to interrupt its developers for the exceptional cases that no-one has anticipated—which is as much about the developers learning what more they need to fix as about getting users over that hump in the meantime.
.
Apple is absolutely, notoriously, abominable at documentation, in part I think because Apple really absolutely hates to admit that its shit ever smells too. But if you can’t own your own mistakes, then you’re never going to fix them and get rid of that stink.
Honestly, I really miss their old NeXt-derived docs from back in the early days of OS X, both in their content and their presentation and navigability. I mean, they weren’t brilliant—good on the Whats but not asogreat on the Hows—but compared to the slop they’ve been serving users these last 10 years those docs were an absolute masterclass. Or even look at Microsoft, who * and* accept their APIs are complex and difficult, and so document the tar out of them so their users can mostly get by for themselves.
.
The other problem is, the health of the developer platform today isn’t immediately, directly reflected in the size of the next quarter’s results. So when the company’s run by and for the beancounters and shareholders, without regard for what the engineers are telling them, they don’t see the need for greater long-term investment. I mean: everything works great now, just look at the size of those revenues!
It not till years later that the knockon effects of those poor upstream processes and resources reach the surface, at which point the damage is far more severe than it ever should have been had they nipped it at the start. Just ask the formerly engineer-led Boeing how that whole McDonnell-Douglas pennycounting culture is working out for them now. Yup.