Why does so much software suck?

In the United States, tractors built during the 1980s and 1990s are in big demand. “Tractors from that era are well-built and totally functional, and aren’t as complicated or expensive to repair as more recent models that run on sophisticated software,” Adam Belz wrote for the Star Tribune in January 2020.

The tractors are extremely reliable and if something breaks down you can get out and fix it or call in a local mechanic. When new tractors break down the farmer must wait for a highly expensive technician to come out who will need to use a computer to help them fix the problem.

Half of the problems faced by car owners are caused by software, according to a 2019 study by J.D. Power. “It’s an issue that J.D. Power claims is down to manufacturers’ desperation to introduce new technology and thus increasing the number of ‘potential problem areas’,” James Fossdyke wrote for motor1.com. I can relate. My car keeps telling me I have low pressure in my tires. I don’t. We kept bringing it into the garage only to find out there was no issue. “I remember the days when we used to test the pressure with our foot against the tire,” the mechanic said, half-jokingly. That’s what I do now.

When it comes to the essentials, it seems, the difference between a 1980 tractor and a 2020 tractor is not that great. However, the difference between a 1980 tractor and a 1950 tractor would have been huge. A 1950 tractor would be an antique compared to a 1990 tractor. For many types of farms, a 1990 tractor does the job just as well as a 2020 tractor and is much simpler and cheaper.

In the last forty years there has been a huge investment in information technology. At the same time, productivity and return on assets have declined. “You can see the computer age everywhere but in the productivity statistics,” Nobel laureate Robert Solow stated in 1987. Between 2010 and 2020, productivity growth in the UK was 0.3% according to the Royal Statistical Society (RSS). “The UK has just had its worst decade for productivity growth since the early 1800s,” Harriet Grant wrote for The Guardian in 2019.

We have too much software and too many features and we’re racing ahead embracing smart speakers, the Internet of Things and AI. In nine out of ten organizations I’ve consulted with over the years, information technology was bought based on magical assumptions. It was as if the very existence of the technology within the organization would create magical productivity and other amazing things. Except that it didn’t.

Most software sucks. Humans are really bad at designing software that is useful and usable because humans are really bad at choosing software that is useful and usable. Software and technology are still caught up in the features arms race, the power, bandwidth, storage arms races. So few of us take the time to stand back and say: What do we actually need this thing to do?

For tech-weary Midwest farmers, 40-year-old tractors now a hot commodity
Tractors built in 1980 or earlier cause bidding wars at auctions.

In-Car Tech Causing Reliability Problems, Study Finds

And the statistic of the decade award goes to … 0.3%

4 thoughts on “Why does so much software suck?

  1. Mike

    The recently released internal Boeing emails around the 737 MAX scandal focused on that team’s derisive comments towards regulators and airlines, but one particular email gave me pause, and ties into your post. When discussing training requirements (specifically, how Boeing could get around expensive simulator training for pilots) one employee said:
    “ I that skill is not very intuitive anymore with the younger pilots and those who have become too reliant on automation.”
    That’s just one person’s opinion, but how does increased reliance on software erode our intuition? How does a journeyman learn their craft if the menial tasks are handled by a machine?

    1. Gerry McGovern Post author

      Good point. I think there’s a general movement away from human skill and interaction towards software-mediated worlds. Also, with Boeing, what we see are the results when they tried to use software to compensate for engineering design flaws in the plane. They thought software would fix the problem and it didn’t.

  2. Nicole Maron

    I’m very surprised to hear you state this, because my 20 years in User Experience finds no agreement with the assertion that:

    “Humans are really bad at designing software that is useful and usable because humans are really bad at choosing software that is useful and usable.”

    Someone in the game as long as you must know that humans who are trained in design are pretty damned fantastic at creating useful and often beautiful software experiences (and aren’t you one of us?). It requires education and training, like any other other skilled profession.

    Leadership failures, in my experience, are always what result in terrible software. Unreasonable timelines, incomplete or unsupported teams, incorrectly targeted research and testing, the absence of research and testing, unclear or contradictory business goals, absent managers, hostile work environments and bro-culture, poorly-implemented Agile processes, and a lack of product vision and accountable ownership. These are why software can be so terrible.

    It’s not that humans are bad at design. And given the correct options, users always choose the more useful and usable one, so they’re not bad at that, either.

    What so many leaders are bad at is supporting the people and processes which are known to work, for whatever budgetary or ego obstacles that exist in their organization.

    “So few of us take the time to stand back and say: What do we actually need this thing to do?”

    Ah, there it is, THAT’s getting to the heart of the matter. That’s what leadership needs to ask at the outset, and they need the right skills in the room to help them answer it long before anything gets built: product mgmt, user research and design, development and QA, and the administrative support required for them to effectively work together.

    Committing to this structure and process are too often treated as a pie-in-the-sky scenario, instead of the standard operating procedure it needs to be.

    YMMV, but I’d wager not too much.

    1. Gerry McGovern Post author

      Hi Nicole, you’re right, it is much more a leadership and management issue rather than a design issue. Though I have seen worlds of design and development that are very tribal, that often don’t care that much about the experience of the person who’d going to use the thing. It’s a complex challenge, though often the root cause is at the feet of management who have unrealistic expectations. As you suggest, we need lots more training in design and design management.


Leave a Reply

Your email address will not be published. Required fields are marked *