Software quality is a decision

The Vinh

1. Software quality ←
2. UX improvements

Software, like all creative media, has become easier to produce over the years. As a result, its consumers experience a broader range of quality that they did in earlier generations, when the only kind of software you used came shrink-wrapped in a box: the kind of software built by big teams in big companies.

Today, people who wouldn’t have written software in the past, now write software casually. And they make different choices about quality.

Casual writing

In the book Because Internet, linguist Gretchen McCulloch explores how the Internet changed the English language. Languages have always evolved, but the Internet introduced a new form: instant messaging.

Instant messaging introduced casual writing: a written form of the casual language that people previously only used in speech. Crucially for the linguists, chat message archives gave them a way to study this usage.

Instant messaging’s casual language wouldn’t work everywhere; it wouldn’t work in a book. Especially if you paid for it. Apart from the difficulty of following a chat’s unstructured stream of consciousness, casual writing for your friends and family uses all of the idioms and other linguistic shortcuts that you know they understand. The general public wouldn’t stand a chance.

Casual software

Programmers hack together (rather than write) one-off scripts that do a specific job, but won’t make sense elsewhere, or later, or to someone else. The same applies to most spreadsheets, and other disposable programs.

Casual software, like casual writing, works for its small audience, but not for the general public. We call the alternative to casual software not formal software, but software products, which somebody pays for.

When you write casual software, you don’t necessarily care about how much time and tokens it cost, let alone whether you saved time. Paid software, by contrast, tends to require a business case, which shifts the focus to the value a paying customer gets, compared to the alternative. This changes the meaning of software quality from good enough to worth paying for.

Low-quality software

Software teams choose low quality, deliberately or otherwise, in several ways. For example:

1. declaring victory early – declaring features ‘done’ before finding and fixing the inevitable bugs
2. half-baked solutions – delivering features that only ‘work’ for people who tolerate a poor user experience
3. getting ahead of themselves – delivering software that hides technical and cognitive debt
4. solving the wrong problem – building features that don’t solve actual customer problems.

Each of these problems corresponds to software development work that goes beyond merely producing the initial code:

1. quality assurance – includes finding, describing and fixing those bugs
2. UX design – includes improving features until everyone who needs them can use them
3. software architecture – includes reducing complexity in the software model
4. product management – includes managing demand risk, and building what people need.

Writing software casually doesn’t necessarily mean doing the work badly. Instead, its low-quality has more to do with only doing part of the work. Work that happens before, during, and after the actual coding.

Casual software doesn’t need these disciplines’ efforts, but the kind of software that people pay for does. The kind of software product that sustains a business also pays people to do this work, with the shared goal of not merely producing software products, but producing good software products.