Hacker News Reader

Comment by tailspin2019 | Hacker News Reader

tailspin2019

Good article, but to me it seems to be co-opting the term enshitification in a strange way:

> Large codebases will eventually reach an “enshittification point” — the point at which bugs are introduced faster than they can reasonably be fixed.

I think of enshitification primarily as an organisational/business phenomenon rather than a technical one.

It doesn’t necessarily emerge “bottom up” as the result of technical debt but from top down as a result of misalignment of values between the brutally commercial goals of the business and the values/goals if its customers. Tech debt and development velocity do play into this but I don’t think it’s the primary driver of it.

The term is a useful one at that level of abstraction imho because we already have quite a lot of language to describe things like this at the lower, more technical level.

View on HN

> I think of enshitification primarily as an organisational/business phenomenon rather than a technical one.

The other two important criteria implied by this new term are that it is deliberate and that it is taken for the benefit of the “author” (company) at the expense of the user.

Bugs are inadvertent and have no intent so don’t match either criterion.

Google’s so-called “integrity” system is DRM for the benefit of advertisers (and thus Google), not users. Intel’s on-chip security manager isn’t for the user’s benefit and adds security risks.

Encrusting photoshop or Word with a million features or back-compatibility with a mistake made decades ago may make the program worse, but are in service of giving customers what they want. It may make the application worse in some ways but the motivation is pro-customer, regardless of the ultimate result. (Note: I chose these two programs bc I don’t even like either)

> The other two important criteria implied by this new term are that it is deliberate and that it is taken for the benefit of the “author” (company) at the expense of the user.

> Bugs are inadvertent and have no intent so don’t match either criterion.

Yes, good distinctions. Very different from inadvertent bugs or routine technical debt.

That caught my attention too. The misuse is especially strange because the author both cites Doctorow and links to a definition in line with Doctorow's usage, before then using it in a completely different sense

https://en.m.wiktionary.org/wiki/enshittification

It isn't misuse - this is just how language works. Especially with what is essentially a meme word.

Language works through shared understanding.

And you know what is meant by "enshittification" in the context being used, you just don't agree with the usage.

Let's not pretend this word has decades of deep cultural and etymological history behind it. It's not a technical term or a term of art, it's a meme. It's something Cory Doctorow came up with in a blog post last year that only a few tech people care about. It's a hipster nerd poop joke.

And because it fits cleanly into a description of anything hipster nerds consider to be "turning into shit," it inevitably will, until people get tired of the meme and move on.

I'm not a prescriptivist when it comes to language; if a meaning evolves that's just dandy.

I do think it's odd to link to a definition of a word as the author does, and then use it differently without explanation (potentially depriving the reader of some interesting insight into the phenomena under discussion, if the reasons are good).

Secondly, doesn't 'misuse'really just mean 'used differently from how most people use it'? In which case, I think the descriptor probably applies, given the word's recent coinage and limited usage

To me enshittification is when the overall usefulness of a piece of software starts going down as more money is attempted to be squeezed out of its users. Agree that it's not a technical phenomenon

This is why I tend to go for the "open" option (eg. open source software) wherever possible.

Not necessarily because it's better. But because the incentive to enshittify it is lacking.

Closed / proprietary ecosystems tend to be nice for a while. And then disappear without warning. Or turn into crap, like a big sinking ship taking all its users down with it.

FOSS / open platforms tend to fork and/or evolve. And (if they survive) improve over time. That I can deal with.

It happens in OSS too, though maybe the reasons there are different. See Gnome for example.

Yep. And thus, Gnome 2 was forked into MATE.

A good example of the forking / gradual evolution I can live with.

> I think of enshitification primarily as an organisational/business phenomenon rather than a technical one.

I will second this. I can't count how many projects were started with a clean design and clean early releases (what worked well), to be later messed up with business changes because the original (business) idea didn't work. And those sudden changes are expected to be implemented usually "yesterday", which adds additional momentum to the project's downward spiral.

> to be later messed up with business changes because the original (business) idea didn't work

If the point of a project was to run a business, I would argue the project was messed up from the start if it could not adapt to the changes. Very little software survives contact with the real world.

I think software should always be written with a known half-life. Code I write for some one-off script is incredibly different than code I write when I expect the code to outlive me (eg in an opensource library that people depend on).

Scrappy prototype code is written with developer velocity as the most important property. I’ll throw everything in one file. Stick to tools I know well. Copy from other projects. Use crap variable names and generally make a bit of a mess. Something made fast can be remade fast if it’s wrong.

Code you expect to last a long time should have tests, CI and documentation. If I’m serious, I’ll often rewrite the code several times before deciding on a final design.

A good engineer should be able to switch between styles based on the needs of the project. And a good company will make those needs explicit to the engineering team and they’ll be transparent and trustworthy when expectations change. (Eg if a prototype is going to stay in production long term, they need to tell the engineering team).

It’s fine for businesses to pivot. And it’s fine for engineers to make quick prototypes to test a business idea. But everyone needs to be on the same page the whole way along.

If you buy apples only later to realize you need oranges the apple project wasn't a failure. Part of running a business is trying what works. Now if you were unsuccessful finding apples than the apple project failed. The overall business might fail but the apple project went off smoothly

I've once worked on a large and old Scala-cats codebase (i.e. Haskel-style, the whole program as an IO monad). I'd say we (the team) hardly introduced any bugs. The language made making whole classes of errors less likely, and the team's disciplined approach handled the rest.

Am I the only one who thinks that the term sounds far too general given the apparently narrow interpretation that's intended by it? When first seeing the word, it literally just sounded like it meant "the process of becoming shitty", and I never would have guessed that it was intended to be so specific. It seems unfortunate that the term was picked primarily for how evocative it is rather than for its clarity.

The En prefix means “causes to be”. Things can become shitty but “en” changes it to a deliberate act. Thus shitification is process of becoming shitty but enshitification is the act of making things shitty.

So, it’s not as general a term as you are implying and definitely the usage in this article doesn’t make sense.

Why does "causes to be" necessarily imply intention? I don't think that's nearly as definitive as you're claiming.

> It’s not as general a term as you are implying

My point is that even if the term isn't "supposed" to be general it definitely sounds like that to a non-trivial number of people, which is why these sort of discussions crop up almost every time the term gets mentioned in comment threads on this site.

If your boss said, "This Wilson project is critical."

And you said "I'll ensure it gets done by Friday."

Would you expect to be fired for failing to take initiative?

It's a word I had not heard before this year. It's made-up. It's a Humpty-Dumpty word: it means what you want it to mean.

NB: all words are made-up!

Sure, you can make up any new term and define it how you want, but people will carry expectations based on the word you pick; if I had been the first one to coin the term "enshittification" and defined it as "the process of making something better", pretty much everyone would be confused, and for good reason. The mismatch here isn't as severe, but almost every time I've seen the term mentioned in comments on this site there's a discussion in the replies litigating whether the usage of the term was correct, which is a tell-tale sign of there being inconsistent expectations around the meaning of a term.

As an aside, it's interesting that the phenomenon of expectations around the meaning of terms goes beyond obvious relationships to existing known words but even to the way a word sounds: https://en.wikipedia.org/wiki/Bouba/kiki_effect

You're not the only one. On my understanding the word is a neologism, hence its meaning isn't "stable" yet.

> I think of enshitification primarily as an organisational/business phenomenon rather than a technical one.

Codebases can enshitified, this is a deliberate action. Having a zombie corpse codebase where bugs grow faster than features is not necessarily enshitification.

An enshitified codebase is created when a product person or a TL spends an undo amount of technical debt on new features or even better anti-features.

Is that a first case of metaenshitification?

Yes, the bug accumulation problem is better described as 'degradation'. 'Enshittification' implies deliberately introducing features that make user experience worse while benefitting only the owners of the platform.

Is someone keeping a list of features that qualify for the label? For example browsers like Safari make it very difficult to export bookmarks to another browser like Firefox, even though a simple json file would suffice.

Suggestions for a term for the phenomena?

Emshitifaction?

The article could have used the term technical debt. To me technical debt happens not only when new code gets added in a sloppy way, but also when the developer experience gets worse.

I really like Egon Elbre's definition of technical debt as idealized effort vs. actual effort to make changes - https://www.storj.io/blog/demystifying-technical-debt

It nicely captures a lot of the usually "fuzzier" things of technical debt, like how code even with no changes and no changing requirement somehow accrues technical debt (you get better, your idealized effort reduces).

crushed by technical debt

Or "defaulting on technical debt".

That'd also play into the whole metaphor of technical debt.

In my native language, we widely use therm "Information explosion".

if you're gonna go that way, you might as well go with shitfactoring

Reply on news.ycombinator.com