May 10, 2021
How Constant Updates Lead to Mediocrity: Apps for Scraps
We live in the time of “now, gimme, I want something new”. Everything seems to lose its value immediately – material or not. Long gone are the days of old programs or computer games where the product remained the same. And that’s great, right? Or… is it? Because when there is no need to change something, when you fix something that isn’t broken, then constant updates only lead to mediocrity.
Just ask yourself, how many times one of your Android apps updated itself and the newer iteration proved to be inferior? Perhaps you ended up with a bloated app that did the same thing, only now it took more space on your phone. If you were more unlucky, the app might have even messed up something in your workflow, which made it harder for you to use it.
As someone who has experienced this from both sides of the equation – as a user as well as programmer – I can confirm two things:
- Users often want constant updates just for the sake of updating, without necessarily having any specific plan in mind.
- Developers, to please their audience, offer such updates without necessarily having a clear picture of what will occur down the road.
As I said, I’ve been there myself. I’ve even made the mistake myself – thankfully only briefly, however. As I’ve mentioned in my post on why I stopped working on my Android apps, at some point I got enough of mediocrity and stupidity, and thought “fuck it, I’m done”.
But let’s take a closer look, to see how this perceived need for constant updates operates, and why it’s so insidious – both in terms of programming and in how it affects us socially.
Constant Updates: Fixing what Isn’t Broken
When I made the first iteration of Narrative Nods – the meaner, leaner, superior Narrative Nods v2 is available here – I didn’t even plan to share it with anyone. I just wanted to practice my coding on something I had a thorough knowledge of.
Later, I decided to publish the app and share it with others, thinking they might have use for it. Many did.
And then popular idiocy – assuring that only idiocy can be popular – began to rear its ugly head.
First there were people who rated the app with one or two stars, admitting they liked it, but it was in English, not their mother tongue. I don’t really care about feedback, yet idiocy bothers me. But for our context, that is, constant updates, another element proved to be much more damaging.
I began to accept suggestions for “improving” the app.
There were people requesting bizarre things; those I ignored. But one thing I did give in to – which, in retrospect, was probably a mistake – was the suggestion to allow more than one character per role.
When Practice Muddles the Theory
In terms of characters, the Narrative Nods app was heavily based around my post on types of fiction characters. The whole theory made perfect sense to me, but many app users seemed to struggle.
Despite my very detailed help file within the app – as well as personal responses to comments and emails – there were users who didn’t understand how a role could be fulfilled by more than one actual character:
Although a story might indeed have an exclusive way of assigning these types – that is, one character is a protagonist, another is an antagonist etc. – it is often the case that these represent groups. By “protagonist” we might refer to three or four people, and the “assistant” might be a whole town or even some other, abstract entity.
In retrospect, I should’ve ignored these users. I didn’t, and ended up – with a lot of effort, needlessly wasting countless hours – changing some core functionality of the app to accommodate these users.
The end result?
I disliked the newer version; it felt unnecessarily complicated. More ironically, most users who had been asking for the change didn’t like it either. “Oh, so I can now use two characters instead of one? But I have ten protagonists!”
Looking back, that was the beginning of the end for my Android programming. I’m not the kind of person who puts profit or commercial viability before my art – here expressed in terms of coding – so I thought “screw it, I’m out” and gave up updating, responding, and overall bothering with any of my Android apps.
Why Constant Updates Facilitate a Vicious Cycle
The answer lies in the paragraph that ended the previous section: I don’t care about pleasing my audience. The thing is, I’m certainly in the minority. We live in the time of “now, gimme”, but this is also the time of “Your opinion is important to us!” The fuck it is… It’s all a giant nightmare of hypocrisy and hurt feelings.
In other words, companies and developers offer constant updates not because they are essential for the operation of their products, but to please their audience. Naturally, doing so only further conditions their audience to request constant updates. It’s a race to the bottom of mediocrity.
Escaping the Trap of Needless, Constant Updates
We’ll see this from the perspective of a programmer; a creator, in other words. The lesson is also relevant if you’re a writer, so pay close attention.
If you recall from my posts on whether art should be free or degrowth for writers, artistic creation and commercial viability are two processes that, almost always, are entirely separate.
More importantly, they are conflicting.
That is to say, artistic creation and commercial viability are, to a great extent, working against each other.
Perfect artistic freedom usually entails very little commercial viability. In the context of fiction, the masses rarely comprehend works that are too far outside the known and familiar – and, if you’re perceptive, you see why “the known and familiar” goes against art. What sells is the 1+1=2, “one minute, then one minute” kind of fiction.
And so, in order for something to be commercially viable, it needs to be diluted, digestible, safe. No room for being offensive or free-styling.
Apps for Scraps
9 out of 10 apps are either mindless entertainment or useless tools imitating one another. Just count how many “flashlight” or “photo filters” apps exist out there.
In this context, with little if any creative originality, app developers feel pressure to keep “improving” their pointless programs. But this is a bit like rewriting a novel. If the structure is wrong, you could write the damn thing 100 times, it will not make it any better.
Similarly with apps, you can keep “updating” an unoriginal, dreary idea, but it will not offer any added value. I mean, come on, how many times can you “update” a friggin’ flashlight app?
So, how do you, as a developer (or writer, or creator in general) escape this cycle?
By understanding what you’re doing and why you’re doing it.
Ethics and Subjectivity
I can’t tell you what to do; the very idea of ethics is predicated on subjectivity. But here’s what I do: I plan and act so that I can see myself in the mirror feeling comfortable doing so.
If I sold my creative soul to the “gimme more” mentalité, I would feel like the biggest fraud in the history of creative writing or programming.
This is an entirely subjective position. If you want to make money, and you have no qualms about producing unoriginal apps with needless updates, this doesn’t apply to you.
Just make sure you ask yourself questions like these from time to time:
- “Am I really doing what I’ve always wanted?”
- “Do I create something of my own, or do I simply follow others’ example?”
- “Am I happy with what I make?”
This last question, in particular, is crucial. In my post on whether good writing can be taught, I mentioned this:
A good writer is someone who is in full control of her/his text, expressing the things s/he wants to express, the way s/he wants to express them […] I believe it’s more productive to focus on the author as a separate entity from the audience. And the only gauge of being a good writer is, ultimately, the author her/himself.
Ultimately, if you’re happy with what you make – happiness can never be objective – it’s all good. But you must be able to answer that question honestly. And this isn’t always easy.
2 Comments
Comments are closed for posts older than 90 days
I have decades of programming experience and I know what constant updates do to products. Even if the piece of software had design integrity when it was first released, as a rule, every update is built on top of what’s already there, making the product a bloated mess, nobody understands it any more. Government apps are a typical example – most of the Canadian government applications are still contain decades old COBOL routines, usually without documentation, when many of the original programmers are already dead. So, any time the government needs a new function, or change an existing one, it is never redesigned but patched, using unbelievable contortions to have a temporary change that will probably blow up in their faces when they least expect it. Prime example is the Canadian government’s payroll disaster that left employees shortchanged and arbitrarily denied. People lost their homes because they couldn’t pay the mortgage because of the government was unable to pay their wages for months and months. See https://www.macleans.ca/news/the-phoenix-pay-system-disaster-explained/
My advice: think it through, do it right the first time and, if you are not happy with it, put it aside and start from scratch.
Very useful information Francis; and I couldn’t agree more with the last piece of advice!