Like an inflatable hammer: Unusable software and its origins

We use software to get things done. We hope these products will help make our lives better, and that's why it's such a blessing to be a software engineer and startup founder. There are an infinite number of things we can make that potentially make things better. Yet as software creators, we fail — over and over and over again. 

Just in the past day, two big brands failed me in major ways through poor software engineering. Last night I bought an Xbox One game and tried to play it. I let it try to install overnight. The software is stuck now — complaining the installer hit network connection issues and won't continue, even though clearly the Xbox One can connect to the Internet. There's no retry button. I'm in a broken state and I don't know how to resolve it. This is a pretty basic use case that is completely broken. 

This morning, I tried to use Silicon Valley Bank's new deposit-by-mail feature. First off, it took me over a week and two emails sent in order for them to enable it on my account. I shouldn't need emails to enable a feature like that, let alone wait a week. Then, when they finally did enable the feature, it didn't work at all for the handwritten checks I needed to deposit. The error? "The amount doesn't match the check image." The engineers probably used some off-the-shelf OCR system that barfed on handwriting. There's no workaround. Yet handwritten checks are a pretty core reason why someone would use a mobile phone app to deposit a check. The core use case is completely broken. 

This is the inflatable hammer problem in a nutshell — too often, we are given tools that cannot be used for their described purpose. They're broken in fundamental ways. 

In the end, SVB and Microsoft suffer from broken product and engineering organizations. These organizations have plenty of resources to make these simple core scenarios work. But it's not a resource issue. These failings usually happen because designers and engineers who actually make the software are divorced from the management organization that sets the deadlines. There's no sense of ownership — merely hitting milestones and knocking off items on a to-do list. I hit my goals — ship it and let's get a beer. 

Large orgs also make the mistake of insulating their product and engineering people from the people who actually experience the pain. There are layers of engineers and management and emails go to account managers who can't do anything about it and don't know anyone who possibly could. When I was a PM at Microsoft, the only interaction I had with end users was reviewing Windows Mobile help newsgroups once a quarter. It was like wading through an ocean of pain. It was so sad and ugly to look at, and that was the software we were making — that was the pain we were inflicting on our users.

Silicon Valley is obsessed with the auteur-CEO for good reason. When MobileMe shipped crap, it wasn't OK with Steve Jobs and clear action was taken. When idiotic product decisions are made, it takes someone with power to lay the smack down and enforce a culture in which that kind of thing isn't acceptable. 

Startups don't have a creaky old dumb organization yet — it's just founders, right? Yet startups ship bad software all the time. Why? Well, founders have limited time, and the advice to ship-fast/fail-fast is a strong driver. We ship software when the basic case works at all. This is probably still the right thing for people do. But then founders forget to fix things that are broken. The moment your software works at all feels like you're 80% of the way there, but you're really at 20%. A great product is made, not born. 

Startups have an even greater chance of success at products because they can listen to users. You don't have many, so you can actually read and answer every email you get. Take a page from Wufoo, who made their engineers and designers do support every single day. This is the best thing you could possibly do. Connect with the pain of your users, and fix the papercuts, no matter how small. That's how you get to a great product. 

Don't make the same mistake the big orgs make. If it sucks, cut scope or slip the schedule. Don't cut quality and don't strand your users in frustrating bugs in core scenarios. Fix it and make it better. Listen to users. Fix it. Repeat. 

SVB and Microsoft can endure a lot of failure before it affects their bottom line. They've got a lot more things going for them — one is a bank, and the other has a few durable monopolies that have decades of life on them still. But for startups, all you've got is whether the damn thing works. So ship it and make it better. 

views
10 responses
Joseph Walla upvoted this post.
Which is it, ship my check-scanning software when it works for some majority of checks, or when it works for all them? On the one hand, I want to provide this valuable functionality to my customers but, on the other hand, I need it to work more often than it fails. If 70% of checks processed today are printed and the product works for 99% of those but only 40% of written checks, is that enough? What's the correct formula? Does the answer depend on the size of my company? The amount of capital/time provided to my section for implementing the feature? The accuracy of my competitors? The opportunity cost of existing customers switching to said competitors until I catch up? What's the formula for calculating that? Do these generic "users" all have the same "core scenarios"? As a founder, isn't it my job to discover those scenarios as much as it is to perfect them? How about their general tolerance of "incomplete" software? I would imagine they'd be far more tolerant of a shitty micro-blogging service that's only available 50% of the time than they would be of a game I (haven't yet) sold them for $70 for a console I have yet to produce. I think you've scratched the surface of a bigger question: how do we make it possible *and relevant* to scale quality with organization size/scope? Forget failing to OCR checks: why are we still trusting banks with our money, *period*, after they've been proven to do such a horrific job of managing risk that we've effectively had to pay *them* not to collapse and take our money with them? I guess the same reason you're going to tolerate your XBox One issues: it's simply too costly in [time, money, opportunity, identity, convenience, pleasure] to punish them the only way they care about--by not giving them your money. In place of that, we complain. And delude ourselves into thinking another cycle of the same process will fix it.
Yeah, good question. Well, we forgive big companies less since they are generally faceless and when you tell them it's broken, they are unflinching and ignore us. Most people are cool with someone, especially a founder, saying "We're going to fix it asap," and then actually have that happen. In fact, that's awesome. The only solution for big companies is often someone at the top with product sense and a willingness to throw people out of the company for incompetence. The solution for small companies is quite a bit simpler.
Another thing startups have going for them on this front is a lack of users who have grown accustomed to the old way of doing things. Once that happens, it's much harder to make improvements to an interaction model without upsetting at least a vocal minority.
The aerospace industry has its problems, but luckily for me (and for you as an airline passenger), this is not one of them. We work until we get it right. And to an increasing extent, resources from around the company stop what they're doing and go help whoever is struggling the most to get it right in a timely fashion (i.e. there's less and less "Sucks to be you! I'm going out to get a beer"). And we know that we don't always get it right despite our best efforts (because humans are human) so we design products to fail gracefully rather than catastrophically. (I'm sure that some sectors of the software industry also have this kind of mentality, such as retail point-of-sale... wait, never mind). But I do still sometimes wish I were still in Silicon Valley, shipping fast and failing fast, trying new ideas, sculpting products from scratch and releasing them out into the world... rather than using conservative methods to develop something that literally takes 5-plus years between idea and commercial product. Both industries are very cool and exciting if you think about them the right way. I appreciate that I get to see the Silicon Valley world vicariously through you and my other Facebook friends.
Team CentUp upvoted this post.
4 visitors upvoted this post.