Toaster Apps
Developers may like to write software, but that doesn’t mean we want to fix your computer (or even know how to fix it, for that matter). Nevertheless, we’re often asked, and sometimes try. A former co-worker of mine used to complain about his neighbor’s constant IT requests. “Toaster Lady” he called her, because she’d say “I want my computer to ‘just work’. Like a toaster.”
There’s a lot for those of us in the software industry to unpack in a statement like that. In particular, I was reminded this weekend that getting software applications to the point where they “just work” can be incredibly difficult.
Part of this relates to the phenomenon of simplicity that I’ve written about before. It takes effort to design interfaces that are both simple and functional for a broad range of users. And there’s a temptation to put aesthetics before all else. Resist it (and read Don Norman’s seminal work on the subject).
Implementation of a simple design is not simple. In fact, it’s often tougher to build code that does simple things well, because nothing is simple with computers. Beneath the Google search box lies an unimaginable stack of data, algorithms, networks, and hardware, all of which works together in concert to find that perfect cat video. It takes an army of people to keep it all running (because everything is always breaking all the time). Not to mention the even larger army of people who designed the individual elements, who could only do so because of the work of even more people whose research and ingenuity gave rise to computing machines in the first place. Simple search? Ha, there’s no such thing.
And the work required continues to grow exponentially into testing. All possible permutations of use cases must be tested to flush out potential problems. Have two buttons? Well, that’s four tests. Add a third, now you’re up to eight tests. Oh, and even that isn’t covering that one weird case where if you press the same button fifty times in a row and then hit button three the software crashes. Now expand that to a box with arbitrary text input? The possibilities are staggering (but not endless; there’s a big gulf between large and infinite, but that’s a post for another day).
Consider all of this next time your technology fails you, and be thankful that it ever works at all.
2 Replies to “Toaster Apps”
Ah spoken like a developer not a QA engineer. ? I think QA would argue nothing should break except extreme edge cases and over time even those reduce in number. There is too much push I see in modern tech development for deadlines over quality and the excuse is often some derivation of the sentiment expressed here. Examples might be the Samsung Note 7 battery debacle that went to market inadequately tested to a company loss in the billions. Yes that was hardware not software but the concepts still apply. Lots of complicated interacting parts creating a large amount of testable use cases that were essentially ignored in order to meet deadlines. The whole failed to test rapid charge capability over multiple uses rather than just once or twice to stress the system was a real world use case ignored.
A software example I’ve observed is in my new Motorola Droid Force Z phone where you can’t play music from Amazon music player or Google play music while location (gps) is engaged at the same time without the processor becoming over taxed and ‘skipping’ soon the music track occurs as if the device is as old school cd player driving on a gravel road. Sure these two applications aren’t written together but it’s not unreasonable to imagine a user wanting to play music while driving and using Google maps simultaneously to navigate. In fact I’d argue that is a really common use case and yet Motorolla didn’t anticipate it, test for it and still hasn’t released a fix for it despite it being a non existent problem in other phones, evidence it is solvable.
Now, having worked with you Jud, I’m in no way implying anything negative on your development skills or priorities. I don’t see you as this type of developer at all. I think you have a keen eye to the development/QA interaction but I think the post here is highly slanted to the dev side only. As a user of tech I think it’s fair consumers insist on basic functionality ‘just working’ and citing complicated interactions as a reason we should be grateful at all for tech is a cop out for the important role good QA plays in making complicated software and hardware seem simple and usable. Users should demand quality and simplicity or it would never push development to produce anything beyond prototypes. I see both sides and the tension between the two points of view that ultimately make great software
Oh, I agree with you. What I’m saying is that making things that don’t break is really tough to achieve, not at all that we shouldn’t try.
My last statement was intended to be an attitude for consumers. It’s a terrible position for a developer to take, and you’re right to criticize it from that point of view.