The Tech Industry is Structurally Incapable of Making Good Software

Once upon a time, when I was an intern at a Rally Software, I won the internal hackathon event.

Rally had a tradition that a few times a year, all the engineering staff would be given a week to work on whatever they wanted, so long as it was tangetially related to company’s products. We could work together, or alone, and at the end of the week everybody would present what they’d done, and we’d vote on our favorites.

Looking for inspiration, I turned to our public list of feature requests. This was a board where our users could submit and upvote features they wanted us to implement.

One of the top requested asks was a “bulk editing” feature: that is, the ability to edit multiple items on our main dashboard at once. The feature request had been languishing on the board for years, and some of my coworkers thought it would be hard to do; our codebase was kinda gnarly and surely this would’ve been done already if it was so simple.

“Ok, but it can’t be that hard”, my cocky 19 year old brain thinks. And surprisingly, I was right! Turns out, a former employee had already written most of the code to do the bulk editing, all I had to do was add new buttons on the dashboard to call the existing code.

I spent a couple of days working on it, presented the bulk editing feature at the end of the hackathon, and it was a big hit. I was voted one of the winners of the hackathon, for which I was rewarded $50 and bragging rights. Not a bad trade for getting an underpaid intern to do one of your customers’ biggest requests.

I tell this story not to toot my own horn (remember, most of the work was already done for me), but because I think it illustrates that making software better for the people that use it often isn’t that hard.

In this case, an intern was able to make a big impact in the useability of a product in under a week. All it took was a person giving a damn, and the space and time to choose what he wanted to work on.

I recently read Robert Kingett’s fiery essay The “Disability Dongle”: Why Silicon Valley Hates Me and you and wanted to write a response based on my own time working in the maw of Mammon.

In his essay, Kingett points out that Silicon Valley would rather build useless flashy demos instead of making software that’s actually accessible:

Silicon Valley will spend millions developing a glove that translates sign language into speech (badly), but they won’t spend ten minutes adding Alt-Text¹ to their images. They will build a headset that describes the room to me (poorly), but they won’t use semantic HTML headings² so I can actually navigate a webpage.

Why? Because semantic HTML isn’t sexy. You can’t put “Used H1 Tags Correctly” on a pitch deck.

There is a profound arrogance in this. It assumes that the only reason I am excluded from society is because I am blind, rather than because society has made a choice to exclude me. The Disability Dongle promises that if I just buy enough gear, if I just encase myself in enough sensors and plastic, I can finally “pass.” I can finally participate.

It’s a lie.

- https://sightlessscribbles.com/disability-dongle (footnotes added by me)

I think Kingett’s words ring true. I think all of us have experienced software that’s buggy and slow, software that just doesn’t fucking work, and it’s all 10x worse if you’re using tech outside of the “happy path” flow that the mostly-white, mostly-abled, mostly-English speaking, mostly-wealthy tech workers have envisioned.

I want to talk about how software ends up this way. It’s not just malice and greed that results in bad software, but also the structural makeup of the software companies themselves.

I believe that the segregated demographics of the tech industry make it so even well meaning people fail to build useful, accessible software. The people in the room are ignorant of what their users actually need, and corporate incentives ensure that they never learn.

Now, I don’t think I’m saying anything novel here. If DEI wasn’t a threat to the status quo, the Trump admin wouldn’t be trying to gut it so hard. But I do have some insight into the tech industry, and people who point this kind of thing out tend to get silenced, so I figured I’d add my voice to the choir.

Software is, for better and for worse, a force multiplier. One person can write code that will end up impacting the lives of millions of people.

We tend to think of this in terms of “great” individuals who make out-sized contributions (e.g. Linus Torvalds who started Linux), but it’s equally true of teams of people as well.

Software like Google Maps, Wechat, Microsoft Word, etc are collectively used by billions, but are built by a relatively small number of people. For a personal example, when I worked on Google Pay, I was in an org of a couple thousand people that built software used by hundreds of millions.

A consequence of this is that the people building the software can’t possibly be representative of the myriad of people using it. But the demographics of American software companies show that they’re hardly even trying.

The company that I won the hackathon at, Rally Software, was a medium sized software company based in Boulder, Colorado. When I was there, there were about 400 people working at it.

The majority of that 400 were men. An even bigger majority were White. Most (maybe all?) of the full time employees had college degrees, we were all getting paid significantly more than the median income for our area, and most (though not all) of us grew up in wealthy (middle class or higher) families. With the exception of one person with type 1 diabetes and another with Lyme disease, all of us were outwardly able-bodied, most only spoke English, most were (at least outwardly) straight and cis, and while I’m sure some of us weren’t neuro-typical, it was never talked about.

Once, I think a year after the Ferguson Uprising, we had a DEI training we acknowledged the lack of diversity at our company. While many of us lamented it, when asked for ways we might improve the situation, we were at a loss.

After all, most of us had spent most of our lives in similar environments.

To speak for my own background, I was born in NYC, lived in a conservative neighborhood of London till I was 7, and then moved back to America and lived in wealthy conservative suburbs of LA and Denver.

My family is White, and aside from a few smatterings of Irish that my Mom learned in school, my family only speaks English. Other than the accents, we don’t have any visible or legalized traits (disability, queerness, criminal records, etc) that would differentiate us from the idealized White American image.

The people who made my suburban lifestyle possible generally didn’t live in the same suburb as me, nor did their children go to the same schools as me. The realtities of car based surburbia being what they are, I usually only interacted with people outside my social and racial class in a service capacity (the lunch ladies at my school, the construction workers who built my house, etc).

In 10th grade I switched high schools to attend our school district’s IB program which even further segregated the students. There was only one Black student in my program, no Native American students, and I think no Hispanic students either. There were also no disabled people in my class.

My IB Math and Physics classes were majority male, my Psychology class majority female (English was a pretty even split). The non-IB computer science class was mostly male, as were the 5 of us who signed up for the more advanced course.

After high school, I went straight to university, studying computer science at CU Boulder, in the same town that I would end up working in for most of my 20s. CU is one of the whitest universities in the country, and the non-white students are more likely to be international students than Americans.

My comp sci program was, you guessed it, overwhelmingly male and white. (This may be less true now, CU dramatically expanded its program after I graduated, and opened it up as a Bachelor of Arts degree, instead of requiring you to get admitted to the more gatekeepy Engineering college).

After CU, I joined the workforce, which only continued the trend. You could generally only get hired into software companies (at least before the advent of bootcamps) with a college degree, preferably from one of the male dominated STEM fields.

Not all of my past co-workers have a similar background to mine, but many do. And the thing about spending your whole life in a segregated bubble is that it feels normal. Even when the discrepencies are pointed out to you, you don’t feel it in your bones, because this is what life is, right? The sky is blue, the grass is green, the people are white.

And so, bringing it back to software, it’s no wonder that our software was buggy, inaccessible, and lacking the features that our users actually wanted. We lived in a completely different world than them.

We experienced few of the pain points that they did and yet we were the ones envisioning what their user experience should be.

Some years after that hackathon, I started working at Google. Compared to the medium-ish size company I was at before, Google was a nearly 200,000 person behemoth.

And yet, despite the larger quantity of people, the overall demographic segregation was, if anything, even worse.

My fellow full time employees were still mostly male and mostly white. We were even richer than my previous coworkers were, and even more likely to come from upper class backgrounds. Despite working in the same town that I went to college in, very few of my coworkers had gone to that school – they were much more likely to have attended an Ivy League or similar.

While there were more non-white employees at my Google Boulder office than at my previous company, the majority of them were immigrants who came from wealthy and socially-privileged backgrounds. If you were American at Google, you were much more likely to be white. Meanwhile, the full-time contractors who did all the “unskilled” labor around the office (including literally building the buildings) were majority hispanic, and, definitionally, working class.

Similarly, at the time I worked there there were more out queer and neuro-divergent people than there had been at Rally – and I witnessed many more stories of discrimination than I heard at Rally too. Out of the closet and into the fucking fire. Google claims that they want you to bring your whole self to work, but then punishes you when you do. So it goes.

And so, the software engineers at Google were even more out of touch with the average person than my coworkers at Rally had been. Which means that, even if they were well-meaning, they were generally ignorant of what would be helpful for the average person.

As an example, I didn’t know what screen-reader software was until several years after I started professionally making websites. The first company I worked at (shamefully) didn’t have a proper accessibility testing process, we didn’t have any blind or low-vision people on staff (hell, I didn’t even know a single person in my life who was blind), and so, our software was probably pretty awful to use with a screen-reader.

Unlike smaller software companies, Google and other big tech companies do hire User Research staff. These are people who run empirical studies on what users want and what user interface designs are most effective, which then informs what gets built. In my experience, it generally goes the opposite way, where the (generally white, generally male, always wealthy) product managers already know what they want to make, and then user research studies are conducted to give them a veneer of being “data-driven”. Studies that contradict the already-planned roadmap are often ignored.

Similarly, Google does have Accessibility (and Security) teams, but, if they’re called in to advise at all, it’s usually after a large part of the project has already been built (or, sometimes, released). At that point, any problems are much harder to fix, maybe the entire design needs to be redone. Nobody is eager to do all that cleanupwork “for nothing”, and so the can gets kicked down the road.

On top of the lack of diversity, Google and other big tech companies have an all-encompassing toxic culture of advancement. Everybody is obssessed with promotion, so much so that we joked that instead of doing Test-Driven-Development, we were doing Promo-Driven-Development.

I have never been an ambitious person, but after six months working there, the culture sunk its teeth into my soul and I became just as hungry for recognition and growth as everybody else. For most people it wasn’t even necessarily a money thing – whether it be a desire for power or a continuation of a society that numerically grades everything you do, few people resisted its pull for long.

This culture has many knock on effects (not the least being all of Google’s abandoned projects), but it’s devastating if your goal is to build useable, accessible software.

You get promoted at Google for launching some new thing that has impact.

Impact was generally measured by how many people used your code, and/or by how much money it brought in. Building something for a small segment of your userbase (e.g. all of the disabled users) doesn’t count as very impactful. Maintaining something that already exists is also not considered impactful, because it’s not driving new growth.

Your promotion packet (a report you write up with “empirical” evidence about why you should be promoted) only included your immediate, recent, successes. You could launch some feature or product that you practically force your millions of customers to use, get promoted for it, and then if it people hate it, or it’s turned off in six months – well, you’ve got your promotion, not your problem anymore!

Together, the lack of diversity in tech and the toxic advancement culture create a quagmire worse than the sum of its parts.

People chasing promotions end up creating products that they think will be useful, but are actually completely out of touch with what people actually want (see all the nonsense demos Kingett talks about in his article).

Even if somebody manages to swim upstream against the promotion culture, they’re much more likely to focus on some problem that is legible to them (e.g. the developer experience, or a feature they use personally) than something that might be useful to the average person, let alone marginalized person.

And thus, software has been shit for a long time now. Add in the tech industry’s mask-off descent into greed and facism at the executive level, the mass layoffs of the last few years, and the cult of AI, and you get a mess that’s not going to be cleaned up anytime soon.

So what can we do about it? At the beginning of this essay (oh my god has it spiraled out of control), I said that talking about this stuff was interesting because it might help inform how we fix it all.

I hope I’ve illustrated how a lack of diverse human experiences leads to software that doesn’t work for the many, but only the few. The fix here is simple, but not at all easy: we need a more diverse set of humans building software!

And then, because no set of software developers, no matter how diverse, is ever going to encompass all of the needs and desires of the people actually using the software, we need processes that empower people to influence their digital (and physical) infrastructure! That feature request board I talked about earlier is a pale imitiation of what we actually need, which is a world in which people actually have a voice in the built environment around them.

I’m not sure how we get there, but, if you’re a software developer yourself, a good first step is just, you know, talking to people who are using your software. Often, software engineering teams are so atomized (I only work on this small part of the product, and that’s all I care about!) that it’s easy to forget about the actual people using your product. Going out of your way to try to meet them, and hear what they need, is a start.

If you work on web stuff, in my “Making Your First Website” workshop, I include a section on web accessiblity. It’s got a list of questions you might ask yourself as you’re making a website, to try and make it more comfortable for the wide variety of people out there. Again, no substitute for actually talking to people, but hey, it’s a start.

There’s also a bunch of articles out there like Falsehoods Programmers Believe About Names which are always a good read.

Some people hope that AI might bridge the software accessibility gap. I’m sympathetic to the idea, and if somebody is able to use AI to make themselves some digital tool that makes their life easier, more power to them. But I don’t believe that relying on AI will get us out of the systemic issues that make software so painful in the first place. After all, the companies that control the AI (e.g. Google) are the ones that are the most symptomatic – in the way that a tumor is symptomatic of cancer – of the problem to begin with! All it would take is for the AI companies to jack up the prices, and now accessible software is only available to the rich.

Finally, the realm that I see the most hope for improving the state of software isn’t technical at all, but regulatory.

The blogger fireborn has a great post called “because fuck you”: why consumer choice is being stripped away and how the tech industry profits from it, where they go over many of the same topics as this essay (and Kingett’s), in even greater detail.

fireborn makes the point that regulations are the only thing that actually compels companies to make quality software:

Regulation moves them. The EU’s Digital Markets Act is producing more consumer-favorable outcomes in the devices and platforms it covers than fifteen years of developer and user advocacy produced. The EU’s USB-C mandate eliminated the proprietary charging standard problem in a way that four years of charging Apple money to make Lightning cables never did. The various right-to-repair laws passing at state level in the US — incomplete and imperfect as they are — have produced more movement on repair policy from Apple and John Deere than decades of advocacy. Litigation moves them. The Epic v. Apple case, even with its mixed outcome, produced changes Apple would not have made voluntarily. The EEOC, ADA lawsuits, and accessibility litigation have produced accessibility improvements that feedback and advocacy alone hadn’t.

I disagree slightly with the idea that advocacy doesn’t work – I think advocacy is the beginning of all successful regulation – but overall fireborn is spot on.

Corporations, like all heuristic driven AI, exist only to maximize their value, i.e. money. Regulations are the guardrails within the capitalist system to keep corporations from killing us all while they make their money. Naturally, corporations are then incentivised to flout and destroy regulations (which is the state of late capitalism we’re in today), but that doesn’t mean we can’t try to set them anyway. It might just be a harm reduction stop-gap, but it’s much better that than nothing. And as fireborn shows, we’ve had some success in the last decade or so, so let’s keep it going!

I’ve been wanting to get an essay like this out of my head for a while. To everybody who stuck to the end, thank you! I’ll have some happier writing for you soon hopefully 😅.