Developer Fallacies

From time to time, web and software developers will use bad arguments to justify their choice of technologies, workflows or org structures, or to disparage others' differing choices. I see this a lot, and I may have even dropped the occassional F-bomb myself. We're particularly vulnerable to making bad arguments because we identify ourselves with being logical. How very wrong we often are.

In this post, I'm going to lay out a few of the fallacies I see frequently and I invite you to submit your own. Some of my examples are hypothetical for brevity, so feel free to shout "STRAW MAN" at me now, if it turns you on.

The gospel fallacy

I'm going to start on one you've probably heard of already, perhaps under a different name. This is the "we've always done it this way" fallacy. Something — some so-called best practice or rule or process — is honoured, unquestioningly, simply because it was honoured in the past. This is a type of circular reasoning.

Now, this "thing" may or may not be a good idea or practice, but just saying it's good because it has been agreed upon is not, well, good enough. This fallacy is named in honour of The Holy Bible, which is treated as unquestionable by some fundamentalist Christians despite some seriously sketchy advice.

"Slaves, in reverent fear of God submit yourselves to your masters, not only to those who are good and considerate, but also to those who are harsh." — 1 PETER 2:18

It's impractical to question or otherwise deconstruct everything, but be wary of accepting anything as gospel. Your software development ancestors, just like the writers of The Bible, may claim to be God-like or channeling some higher power, but this is never evident.

Being wary of the gospel fallacy is especially prudent regarding assumptions about users, their behaviours and preferences.

The Luddite fallacy

The Luddite fallacy is essentially the opposite of the gospel fallacy. They are two sides of the same coin, if you like. Named for the textile workers, the Luddites, who resisted the new technologies that threatened their livelihood, it takes two forms:

For example, you might be accused of "not liking change" because you resist moving a project from one technology to a new one, when really your reasoning is that the new technology is wank, for which you can provide justification. The fallacy will be trotted out to mask any valid arguments, making it a form of ad hominem attack.

Developers have a tendency to be self-serving in their choice of technology. There is a strong urge to adopt a new technology just because it's a fun new toy to play with. Of course, they'll never admit to that openly, but they might rely on some form of the Luddite fallacy with which to bargain. Be aware.

Here are some examples of some things that have been recently conceived which are fucking terrible.

The scale fallacy

This is one I get a lot because I tend to favour simple solutions to things, in my writing about web development. The accusation takes a form akin to, "that's fine for the simple thing you're doing, but it won't scale." Exactly what is meant by "scaling" is never made clear, nor can it be — it's too vague of a concept. In any case, the scale fallacy covers two illogical assumptions, depending on the context:

Is the popularity of an application proportional to how much code it is written with? No, of course it isn't. In fact, there are any number of examples where quite the opposite is true. To claim that a convoluted codebase is the inevitable result of expanding the reach of a product is fallacious. Don't be George Lucas. Sit on your fucking hands and stop adding bullshit features.

Equally, there's no reason why serving 10 pages of content versus serving 10000 should be any different in terms of mechanism. They often are different, but there's no reason, in isolation, why they should be. The number of records in a database has no relationship to the complexity of that database's overall structure.

The clunkiness of publishing systems cannot be justified by the number of their consumers.

The chocolate fireguard fallacy

Some things are just not fit for purpose. Some things are just better not existing or being replaced by other things. You should never accept this without investigation (see the gospel fallacy) but not everything can be excused with the apologistic, "so long as you use it responsibly, it's perfectly fine." A cot made out of barbed wire? Sure, so long as you're careful!

It stands to reason that the eponymous chocolate fireguard is never likely to make a worthy substitute for a wrought iron one. Sure, you can still use a chocolate fireguard if that's how you win a bet, but you're going to make your life difficult. It would take little effort to demonstrate this. For example, you could light a fire.

I may — and I did — assert that nesting is a poor language feature of Sass. My argument was that it arbitrarily increases syntactic complexity, inevitably diminishing the readability of the Sass source code for no benefit. You're perfectly welcome to dispute this, providing examples of nesting increasing the readability of your code where possible or by demonstrating other benefits.

However, just saying, "like anything else, it really depends on how you use it" doesn't answer my claim that nesting cannot improve Sass code. It's just a dubious assertion that literally everything has the same value and utility.

The pull request fallacy

The pull request fallacy is a kind of rhetorical diversion tactic. It claims that your grievances about the nature of a certain piece of Open Source Software are invalid because you could just send a pull request to fix it; that all OSS is, therefore, beyond reproach. Recently, I posted this tweet quoting an observation about the arguably confused state of contemporary javascript syntax. This was met with the suggestion that, because it's open source software, I could just go and "fix it".

I really wouldn't know where I would start with this pull request, since it would have to address a huge body of decentralised standards work and proprietary API code, culminating in the provided snippet. But that's not the point. Just because Github exists doesn't mean I don't have the right to pass comment on development culture or the dubious fruits it sometimes bears.

It is also naïve to think that fixing some code via a pull request will inevitably fix the culture that begat it. Not everything is a discrete bug that can be reduced to a ticket/issue, anyway. Some things are fundamentally flawed in their design. See the Bob The Builder fallacy.

The 'made at Facebook' fallacy

This fallacy is reminiscent of the generic "appeal to authority" fallacy, wherein you point to an authority figure such as a scientist or published author stating that what they say must be true.

In web development we often look to famous, successful organisations for inspiration; Google, Facebook, Microsoft. We make the mistake of attributing their success to their development practices and look to cargo cult success by adopting the same behaviours. There's no reason why a successful organisation is necessarily a functional, efficient or technically capable one. Just look at the Tory party in the UK.

Organisations like Facebook have huge development teams where communication and knowledge sharing is necessarily more problematic than in small, closely knit teams. Should development practices evolve to overcome this problem, then they are only valid where the problem actually exists. Aping them isn't going to help you.

Did you know OOCSS (Object Oriented CSS) was developed to help Facebook with their woefully organised and redundant CSS? Do you know who came up with it? An independent consultant.

The Bob The Builder fallacy

The Bob The Builder fallacy is symptomatic of the piecemeal way we tend to approach web development. It can be summarised in one phrase: "A problem with the design has been verified, therefore it must be fixed".

When using ticketing systems, which describe tasks independently, it's tempting to just soldier through, tackling anything we know how to tackle. It's important to first ask whether a given task should be tackled, what its wider implications are for users, and what sacrifices would have to be made in terms of systemic simplicity or robustness.

I provided a fictional dialog illustrating the myopic way we approach problems in my article, Things To Avoid When Writing CSS (part 2):

“Hey, I’ve got these three adjacent ‘calls to action’. They each have a picture, some text and a button (well, a link). The trouble is, the text is different for each, so the buttons don’t quite line up horizontally.”
“Okay.”
“Well, I mean it doesn’t look right. Is there a way you could fix it?”
“Well, technically I could set the same height for each call-to-action (leaving enough room for the tallest), then position each button absolutely along the bottom line of their container. But I wouldn’t — “
“That sounds great, do that!”
“Well, have you actually finalized the copy, because — “
“THAT SOUNDS GREAT, DO THAT!”
“But, when you reduce the viewport, the text will wrap and — “
“THAT. SOUNDS. GREAT. DO. THAT.”

When it comes to communication design, nothing is black or white; broken or fixed. Not everything is a bug. Some things are limitations, and some limitations benefit many more users than the few that a "fix" would address. This fallacy is named for the children's television show, Bob The Builder, for which the theme tune goes, "Bob The Builder / Can he fix it? / Bob The Builder / YES HE CAN!"

Yes, he can, but should he?

The real world fallacy

The real world fallacy comes about when you express an idea for a new development practice and a member of the community disputes its veracity on the basis (for whatever reason) that their company/organisation would not want or be able to adopt it. The truly fallacious part derives from applying their specific assumption generally, making the mistake that because it wouldn't work for them, it necessarily wouldn't work anywhere else, for anyone else.

That is, by assuming their experience is universal, they cannot imagine anyone "in the real world" would ever take the notion seriously.

As an addendum, it's probably worth pointing out that "the real world" — the one we live in — is our responsibility. The real world is what we make it. Since your agency is undeniable, using "this would only work in an ideal world" as an excuse tells everyone you're reluctant to help change the world for the better.

Ask yourself: Am I The Establishment?

The Daphne & Celeste Fallacy

The Daphne and Celeste fallacy erroneously puts that ugly looking code must be poor code. It is typically the domain of coddled and self-regarding developers who prioritise the readability of code by themselves over its utility to users.

One example is the addition of WAI-ARIA attribution. Yes, it makes the code "uglier", but it is there for an important reason (providing semantics to AT users). To suggest that its ugliness is, by extension, "hacky" or low in quality would therefore be incorrect.

Here's an example of some CSS:


:nth-last-child(-n+6):first-child,
:nth-last-child(-n+6):first-child ~ * {
	/* properties here */
}

This CSS does something useful: It styles sibling elements if there are six or more of them in quantity. It is quite difficult to read if you are not familiar with advanced CSS and it should probably follow a comment that explains what it does. It also covers a relatively obscure use case. None of this means that the code is badly written or lacking in utility.

This developer fallacy is named after the erstwhile pop duo, Daphne & Celeste, who sang "U G L Y / you ain't got no alibi", which is equivalent to "U G L Y / you have got an alibi".