So I’ve been bouncing along using my iPhone, iPad and Macs for years, and, like the proverbial frog in boiling water, have been putting up with stuff. I won’t bore you with a list of irritations — we all have them (*oh, OK, I’ll put one at the bottom of the post). I had workarounds. I rebooted regularly. And then on Monday I read Jean-Louis Gassee and found myself nodding in recognition — quality problems! bad design choices! — and the water suddenly seemed pretty frickin’ hot:
I’ve gotten a bad feeling about Apple’s software quality management. “It Just Works”, the company’s pleasant-sounding motto, became an easy target, giving rise to jibes of “it just needs more work”
It turns out his awakening was triggered by Marco Arment’s post which in turn started a general pile on (he later posted that he regretted his original — but the train was many miles away by that time, and gathering speed).
I have tremendous admiration for what Apple has achieved in the past fifteen years. The tech world has never seen anything like it, and may not for a while. Heck, the business world has never seen anything like it. So rather than putting our own boot in , let’s look at how this can happen, even in a very highly functioning company like Apple, and maybe learn some things about how we can avoid a Quality WTF of our own.
Establish in the Culture that Quality Matters
Easy to say. In fact, almost everybody says it. Executives love to say it (I’ve done it myself). Doing it takes work, and a real prioritization of effort at multiple levels of the organization. Here are some suggestions:
- use the software. And care about it. Yes, even as the CEO, and definitely as VP of anything to do with products. You think Apple would be having a problem if every engineer in the place thought that at some point Steve Jobs would call them out on their work? No. Right?
- talk to customers. Yeah, yeah, you do that. But at Apple either a) the executives are not talking to customers or b) they don’t care. Which is worse? You get to decide. There are lots of ways to do this: sit in on tech support calls; have the engineers sit on tech support calls; get out of the building and watch a customer use your product; set up a few phonecalls a week with customers using early versions of your product. Phonecalls are better than emails — tone of voice is important — “the software is great” can sounds very different when it’s spoken. The point here is to see the emotional reaction — to understand what it’s like to try and use something crappy. That you built. You’ll be embarrassed. That’s good. It’ll save you money, and possibly a lot more.
- make it clear that releases won’t be going out until they’re ready. Yes, than can hurt — it costs time and money. But not as much as having a reputation for crappy software (and, yes, I’ve been on both ends of that).
(True story: I was at an event at Microsoft once, many long years ago, when an exec from another company cheerfully informed me over drinks that they weren’t going to use our software any more. “Too many bugs” he said. Embarrassing. I didn’t enjoy the flight home. But it got me off my ass and we fixed it — it took a while — and eventually went public. Ta dah!).
Teach the Craft, Part 1: Design
You have people in your organization that know and really love great software, and are passionate about describing it, in detail. Find them. Have them spread their knowledge and point of view.
What makes a great design? What are the details behind “just works”? This is not magic, it’s craft. Teach the craft.
Teach the Craft, Part 2: Architecture and Coding
You have people in your organization who are excellent, clear architects and coders. Their approach to problems is elegant and sparse. Find them.
What makes a great architecture? Who can review an architecture to take it from good to great? Spread the knowledge. Everybody will thank you.
Nobody Wants to Do a Bad Job
Bear this in mind. If your teams are starting to put out crappy software it’s because you’re a) letting them and b) not giving them what they need to do a great job. Fix it. Remember — everybody loves building something great. Everybody.
Get the Right People In the Right Place
Sometimes, it’s just the wrong team. Some of the speculation about Apple is around the fact that the stock has risen massively, people are ready to move on, and the new generation just aren’t the right people.
Could be. It happens. You need to make sure the right people are doing the right jobs. All the teaching in the world isn’t going to work if you’re making engineers who are passionate about massively scalable server architectures do UX work. And vice versa.
And some people maybe aren’t up to the job. That happens. Perhaps you have to do a wholesale change — a turnaround. That’s tough. But be sure you’re doing the steps above before going here. Remember: nobody wants to do a bad job.
Take Care of Your Architecture
The issues at Apple look to me mostly to be polishing stuff: that is, not paying serious attention to the last 5% of the job (which is, of course, the hard part).
But something like iTunes looks like a different problem. That looks like a ton of code that got piled up over years and is just ugly inside.
Don’t let this happen. This one takes a long time to fix. Make sure you have an architect that cares, and when they come to you and say “you know, we need to take a couple of months to make sure we have a long-term base”, don’t even think about it — do it.
Don’t indulge in Ideological Design
The stuff that bugs me most about the Apple issues aren’t so much the bugs — those can be fixed with attention to detail. The things that are most distressing are what I’d call Ideological Design. This is where the product design serves the company’s goals, not the customers’ (and, yeah, once you think those are different, nasty slippery slope).
Just a couple:
- iOS Music always starts in Radio. I don’t use Radio and I never will. But it gets stuck in my face several times a day. Not the album I played last. Not the artist I like. Frickin’ Radio. Yeah, I know Apple is behind in streaming music, but please…
- Pages has been ruined, I mean really ruined, by the idea that it should be compatible between iOS and OS X. This is an Ideological position, not a customer need. And to match that position, whole features have simply been removed (outliner anyone?), and things like paragraph styles, which we’ve known how to do since about 1987, have been broken. Ugh.
There are many more (“save as…” anybody?).
Don’t do this. If you are trying to strong-arm your customers for “strategic business reasons” you are making a mistake. Pure and simple. (And, yes, I’ve done this one, too. And I apologize. I’m not going to say what for. Oh, OK, the Shockwave Remote — never heard of it? Good).
A Word About Process
Process has its place in this. Code reviews, good QA teams, strongly managed customer testing — all that. But don’t (don’t!) rely on it. The change to good software will happen if the teams know that good software is expected, and they have the means to do it. In those circumstances, good managers will construct processes that support the primary goal of building and shipping something great.
Build Something Great
Building great software is an art, and to be able to do it for money (probably pretty good amounts of money) at scale is a privilege. When there gets to be a lot of it (software — and money), it becomes easier to lose some of the art, and the sense of privilege at being in service to your final user.
I hope the notes above help you build something great.
*My Gripe (I Have Many More)
My lovely Thunderbolt monitor goes to sleep, and the won’t wake up until I unplug it and plug it in again. Which defeats the purpose of having the computer stashed away under the desk. Yes, it’s fixable, if you go to an online forum, on which not a single person from Apple has commented, open up the terminal app and hack the hibernation settings — kind of the way I used to manage my computer in, say, 1981. OK, gripe over