No. I do not.
Stockholm syndrome is a condition that causes hostages to develop a psychological alliance with their captors as a survival strategy during captivity. — Wikipedia
I’ve been asked by several people why I continue to use Apple products when I tweet about an almost continuous stream of bugs and idiotic design decisions. Surely, if Apple hardware and software is so bad, I’d be better served moving to Windows or Linux. Let me try to explain why that’s not the case.
(Skip to the TL;DR)
This could be a long story since it spans my entire career, but let me compress it to the highlights.
Since I first became involved in software design out of university, I’ve had the knack of being able to find bugs in products that people thought were robust. Until I showed up.
My earliest memories go back to the mid 1980’s when I discovered a serious defect in IBM’s Special Real-Time Operating System (SRTOS) used in their Advanced Control System at the Esso Strathcona refinery in Edmonton, Alberta. It had been present for the entire life of the OS, about a decade, but nobody caught it. It was in their timer routine. The first tick of a new timer was always too short. Since we had access to the source code, I found the 1-character error in a line of code, applied a fix, and it worked great. IBM was astonished when I reported it to them. In the 5.5 years I worked at Esso, I was the primary person responsible for increasing the system reliability from 96.8% to 99.8%. The vast majority of bugs in the 2.5 million lines of high-level assembler were there when I started. I became expert at analyzing crash dumps and fixing bugs fast.
When I worked at Bell-Northern Research, which was later folded into Nortel, I was the go-to person to test software, even though I was a developer and later a manager. In my C-level group, people would declare their software ready for production but they would be cautioned by people who knew better to, “Run it by Tom. That bastard will probably find a bug.” Developers took this as a challenge to see if they could have me test their software and not find a bug. They would bring software to me that they knew had no known defects. They came in with a smile and left dejected. All failed the first time. All of them. The same has been true in every subsequent company. Not one person’s software has escaped unscathed the first time I test it.
When my staff were preparing for a critical demo to important customers, I was asked to perform the dry run well in advance. Every single time I encountered defects. Even though the developers had run through the exact same script, I would come in and the test would fail in some way.
Now, none of us were superstitious, or believers in the supernatural, or jinxes, or luck. But we all agreed that I could not be present for the customer demo. I had to wait outside the lab. My staff, myself, and managers all the way up to the VP knew it made no sense. I should be able to be at the demo. But we thought it best for me to wait outside the lab until the demo was over before I entered the lab to answer any customer questions. All the demos were a success. When big bucks are on the line, you do what works and don’t dwell on how silly it is.
We were in the market for a sophisticated protocol analyser. A salesman brought me his top-of-the-line unit that cost $100,000 in 1995 dollars ($150 k today). Within no more than 5 minutes of me trying it out, I crashed it so hard it wouldn’t reboot. The salesman walked away dejected. We never bought that unit.
In another company we had shared offices and lab. We all had those 150 lb massive 21″ CRTs that cost a fortune. As I was walking out of the lab, someone called to me and I stopped beside the guy’s desk nearest the door. Literally within two seconds there was a loud bzzzt, a puff of smoke, and the guy’s CRT died. He looked at me in shock and said, “TOM! Why did you have to stop here?!”
For my final story (oh, I have many, many more), I was working on a large web site with tens of thousands of pages of content. The content was developed by one group, and the group I was in packaged it for display. The site had been in operation for many years. I showed up as a contractor and in the process of routine improvements, I came across a major architectural bug causing significant loss of content, or access to existing content. I corrected the build files while decreasing the code size by 2/3 and halving build time. When this patch was put into place, the department responsible for the content were furious. They thought our group had submitted new content. No. The existing content just wasn’t available on the web site until I corrected the bug. In years, not one person had noticed. Then I came along.
Historically, I find bugs in everything I use. It doesn’t matter what operating system, development methodology, or software language. I find bugs in them all. I don’t go looking for them. I don’t hack the OS. I just use the system in the way it’s supposed to be used.
I’ve been using Apple products since I bought my first Macintosh 128K on March 1st, 1984. Over the years I’ve used a lot of Apple products at home and at work. At one time, Apple did make very robust hardware and software. But I’ve seen a steady decline in the quality of their products for years now. I was ragging on them long before the tech press woke up and started smelling the stink of decay.
I don’t use Windows or Unix/Linux much, and so I seldom see defects there. But when I do need to work with them for a few months, I too shake my head at what I see. How can I, as an infrequent user, see these defects that Windows users with decades of experience don’t encounter?
With 33 years of experience with Apple products, I have built up a very customized workflow of shell scripts, Perl & Python scripts, and AppleScripts. I depend on many utilities for my daily, weekly, and monthly chores. My experience allows me to find solutions for many of the problems I encounter. To leave all that behind and move to Windows or Linux would cost me an enormous amount of effort to get back to what I have now. And for what purpose? I’ll just start finding defects in those OSes and get frustrated with them.
Then there’s the cost of replacing the hardware and software. Even if I only replaced my primary computer, a Mac mini bought in 2012 (I’m embarrassed to tell you how many other Macs of various vintages I use regularly), the cost of it would be swamped by the cost of replacing the software I use, let alone the effort of finding equivalents. Similarly if I were to replace my iPhone with an Android device. I’m not a rich person. There are many other things I want to spend my money on.
I won’t switch from Apple products because of the enormous knowledge base I’ve built up, the effort to replace my workflow, the cost of replacing hardware and software, and most importantly … I’ll just find bugs in whatever system I use. It’s what has happened to me my entire career.
I’m going to keep pointing out Apple’s awful product quality. There’s no excuse for a company with those kind of resources to have quality that poor. I know from decades of experience in high-reliability and safety-critical systems what level of quality can be achieved with a tiny fraction of the resources available to Apple.
So no, I don’t have Stockholm Syndrome as I don’t speak fondly of them. I take them to task when they deserve it. I’m not a willing captive. I’m more like Colonel Hogan from Hogan’s Heroes who may be in a prisoner of war camp, but is always sticking it to Colonel Klink (A.K.A. Tim Cook).