But, in my opinion, it’s absolutely required for complex systems, and complex problems often need complex answers, despite the wish for simplicity (which can sometimes happen, but less frequently than people might think).

I had an online back-and-forth, the other day, with someone that didn’t seem to be able to grasp the fundamental concept (actually thousands of years old) that big things tend to be aggregates of lots of small things, so it’s a good idea to make the small things high Quality, as you go. It was interesting. One of those things that seems obvious, to me, but I guess isn’t, to a lot of folks.

It reminded me of that “Eat Less, Move More” SNL skit, where people can’t understand that eating less, and moving more, is a great way to lose weight. There must be some shiny tech, or popular book. You can’t simply take care in every little job, so the big ones work out.

I do think that the current lack of personal investment, by engineers, in their vocation, doesn’t help. When someone only stays at a company for a couple of years, or less, that’s enough time to do a half-assed job, but not enough time to be responsible for maintaining it. It incentivizes churning out a lot of shoddy work, quickly.

That’s not really the fault of the IC. The executives are the ones that establish the corporate culture, and retaining talent doesn’t seem to be high on anyone’s list, these days.

As you said quality is expensive, and is hard. Because needs iteration, blood, sweat and tears. And masses of engineers (of any kind) is in this for money, not for their passions. To be able to build quality $SOMETHING, you need to go slow, pour yourself in the thing you're building. You need to think like a craftsman, and be one with the thing you're building.

Companies want "MVP in 48 hours, product in 4 months, exit in 12 months". So, people glue what they can find together to build, without any regard for quality (or anything really).

This kind of environment is not conductive to quality, but only littering.

The most important thing is all of them go slow. Without rushing. They don’t race. They release when they are done. And it shows.

Ah, also there’s CameraBag, which spent their last year optimizing first, adding more features second.

The problem is the incentives large public companies have are to do well short term, keep investors happy and get the management their bonuses this year, or maybe next.

Those are all for-profit. I have paid for BBEdit for over 30 years.

Also, OmniGraffle is a standard tool, and I have been paying for that, since 1.0.

Same with ForkLift. I don't think that any of these are actually open-source.

    • Good

    • Cheap

    • Fast

    Pick Two

Quality is expensive, but lack of quality is also expensive.

Low-quality software causes customer churn, increases implementation time for new features, causes more incidents, negatively affects your reputation, etc.

Moving fast is the right thing sometimes. But overall, quality is the way.

Extra time spent doing the work well is easier to quantify as a cost than some issues down the line.

Low quality costs money, but only in time, and it's hard to pin down an exact cost. How much of an outage was caused by a quality shortcut? What percentage of our morale issues are caused by working with bad code? And how much, exactly, do those issues cost us? Was some specific quality compromise one of the straws that help break the camel's back?

Much harder questions, and the causes are often not clearly linked to their effects. Combine that with the human predilection for shortsightedness and our dislike of delayed gratification and you have a system that is stacked against quality.

I need to keep issue counts in the single digits (with the digit preferably “0”).

I use a lot of dependencies, but I wrote most of them. Each is released as a standalone project (usually Swift packages), and testing code usually dwarfs implementation code.

I write about my testing approach, here: https://littlegreenviper.com/various/testing-harness-vs-unit...

There must be some sweet spot between poor and perfect where (a) the quality is good enough to prevent greater than expected churn and (b) increasing quality anymore is so expensive that the additional profit isn't worth it.

When NASA sends a rover to mars, the launch/space travel costs are so high that they can justify investing heavily in quality. That balloons the price of course, and that limits the number of projects they can do. The goal then is to make higher quality cheaper, or to make higher quality unnecessary (e.g. through cheaper launch/space travel costs).

I can't imagine it is much different for the software industry (where quality requirements are not as high as aerospace).

Mercedes is better, but a fair bit more expensive. Bentley, Lamborghini, etc., are inasnely more expensive.

Toyota, Honda, etc. are decent quality, though not at the same level, but are a lot cheaper.

Of all the companies I mentioned, Toyota probably makes the most money (I have not bothered to check the financials, so I could be wrong).

I guess it depends on corporate mission.

You might be referring to longevity and ease of maintenance quality, and ChrisMarshallNY might be referring to 0 to 60 or some other nebulous driving performance/style/fit and finish related quality.

Price/status signaling/size/speed/longevity/etc, lots of different parameters to optimize for and lots of tradeoffs and lots of customers who optimize for different qualities.

For basic dependability, there are a ton of good manufacturers, these days. The whole industry has advanced, quite a ways.

But the "fit and finish" Quality (or the car is so fast, you get three speeding tickets when you buy it Quality) are ones that can add serious price to the sticker.

I have a few friends that drive BMWs. They are really nice cars, with a lot of things that I consider "frou-frou," but would definitely like, if I had the money they do (so buying a Beemer isn't a big deal to them). They can afford the premium, so they spend it.

I worked for one of the top camera manufacturers in the world. Their kit cost a lot more than many, and their main Quality axes were Image Quality, and Dependability. Major-league shooters based their entire [successful] careers on our kit. Their skill was the main determinant, but our kit allowed them to do what they do best.

If certain types of Quality are important, then the extra premium is worth it.

Lots of people write lengthy posts nagging about quality and usually these people work in qa or software dev where they get paid for it and mor quality is more work safety for them.

But no one wants really put their own money. Where fixing even trivial bug is 1h of work because someone has to write requirements, someone has to code it, someone has to check if it works and did not break something else.

1 hour on b2b market is $70 or $100 - no one is going to pay that to fix small issue.

I drive 10 year old car it has some issues and if I would go to car mechanic it would be $50 an hour - even if it would take 1 hour to fix all I am not willing to pay for that.

No one wants to pay for 100% quality.

Managers throw more people at the problem to improve productivity, only for the new people to need training. Okay, let's have the new people develop everything from scratch. Wow, that's fast... initially, but they throw code quality out of the window to reach feature parity asap, crippling productivity in the process again. Rinse and repeat.

Or, or... give people the time to improve things. Nobody wants to pay for quality in software until they realize how much it costs them to neglect quality. Unfortunately, some people never realize, cut their losses after a dozen rewrites, and launch the current half-assed iteration. No, it didn't work out for them.

When I am done with my car I just get a new one.

Yes there are software projects that need high quality but it is not 90% of cases.

I've seen it firsthand: Major update to our only software product. Years of work. Everything is moving too slow. Managers hire more people. Performance tanks due to training the new folks. Our publicly available software is abandonware, all hands on the major update to get it done. A few customers switch to competitors, but hype is high for the new update.

After 5 total rewrites, they cut their losses and launch the half-baked current iteration. Launch feels earth shatteringly disappointing and insulting to all stakeholders, even including the developers of the major update. Developers receive death threats. Many developers leave the company. Remaining customers flee to competitors.

Lessons learned: Don't cheap out on quality. It can quite literally cost you your company. Nobody needs absolute quality, and that's impossible to achieve, but at least try to care about quality.

I don’t write about no quality. I write about reasonable level of quality.

I argue against “everything has to be perfect”.

But there's no market for this. And even then in many (likely most) cases the perceived user-facing quality is just irrelevant. There's no effective advocate for this.

Or another skit "Don't buy stuff you cannot afford."

https://m.youtube.com/watch?v=R3ZJKN_5M44

I should not have to "manage up". Management should just do its job.

I hate this. People have strengths, even if they’re all technically backend / frontend / whatever. Should you have more than one person who can perform a given task? Ideally yes, but let’s not pretend that Alice isn’t objectively better at SQL than James, but worse at async functions. Let people do what they’re best at, and enjoy the most.

Management wants to have its cake and eat it too. I feel like if you object to an estimate, you must have to do the task yourself with the reduced estimate. This falls flat because I suspect my manager has ZERO programming/qa/development or even business analyst experience.

Just my personal opinion that if you think the estimate is wrong, you should take the task yourself and do it in less time or shut up.

You know how we talk about developers not able to do fizzbuzz with ten years' experience? I suspect he is whatever the equivalent of that is for managers.

My observation is that doing a 'good job' is not really measurable the way most companies think about it (it actually is if you talk with your actual end-customers or use your brain) but getting something done 'quickly' or 'in two quarters' makes an easy target people shoot for.

I also notice big companies tend to have goal setting practicies that basically encourage people to game the system by showing 'what they got done' ("implemented feature a") vs. 'how well the job was done'. I haven't seen any of these goal systems including a "look back" or feedback loop where the actual bugs filed against a feature are ever considered.

Quality engineering culture is really culture and has to come from the top down and very likely if people in the upper echelons of management are in their roles because of politics, quality is so far removed from what they care about it really ends up on the shoulders of a few individuals who "care".

I also presumed that if I worked at a big tech company, I could file bugs for all the rough edges I encounter using their products and get them fixed. That allure wore off after frequently getting no response until the responsible team declares "bug bankruptcy" years later. The few major products that do have QA seemed to be staffed by incompetent offshore call centers. You file a bug that says something like "this div is missing padding" and it'll get routed back to you asking for you to attach logs (because some training somewhere must say all bug reports need logs). There's frequent "I told you so" ferver when a bad review comes out, echoing all the feedback some PM roundly ignored during dogfood.

I've found a good day-to-day team which has kept me around so far, but there's always the back 40% of my mind wondering if I should quit, sell all my stock, and stop using our products. It's depressing being surrounded by so many talented individuals, yet seeing the company make boneheaded product decisions and show total indifference to the quality of what it ships.

Everyone seems to have collectively forgotten how cool it felt to use gmail back in the day, for example. Getting an iPhone 3GS was, for me, magical.

But the incentives and economic realities are so vastly different right now, I wonder if we'll ever recapture that spirit.

The reason is what you wrote later: it's not fun and they don't do it properly (e.g. full test case instead of testing just changed part) and they know it.

The manager just has to recognize that 80% of the time this will mean a 20% increase in dev time while the tests are written, and 20% of the time it'll mean a 400% increase while things are refactored to remain testable.

It sucks. The rest of the business doesn't get it. But the alternative is that you end up painted into the same corner: in need of that drastic refactor, except the people who it's blocking (QA) don't feel empowered to do it, meanwhile the devs just keep shipping features because they're not the ones that are blocked.

Better to take that occasional slowdown than to have nobody owning it at all.

There is no incentive to produce "quality" (for a meaningful definition of quality).

I see it in the small (with small startups) with some designers; sweating (spending large amounts of time on) the small stuff that turns out to make 0 difference in money terms. Pride in your work/quality is something else than that, but you cannot explain this to your money/growth focused partners.

I agree with your general sentiment in that the general populace is OK with minor annoyances given a cheap price.

Like, prefacing a company memo this way [1] would probably be career-limiting.

All things emerge, change, and die. I think Quality is the experience of the process. The idea of Good Quality essentially boils down to performing the process with grace, and leaving the place better than we found it.

[1] https://www.evalapply.org/posts/how-to-not-die-by-a-thousand...

(edit: clarify opening sentence)

- competitive or zero-sum performance evaluations (aka stack ranking)

- short evaluation windows (3 months or 6 months)

- two consecutive bad evaluations get you terminated

- KPI-driven evaluation: if you can't show numbers, you didn't do it

This basically means:

1. Someone investing time in creating long-term value will always lose out to someone focused on short-term value and may actually get fired by this system.

2. Certain types of projects will never be worth doing in this incentive model. Quality improvements that can't be quantified are not worth doing. If it costs 10x more effort to quantify the impact of some work than actually doing it, that work will never get done. Any project that spans longer than the evaluation window (either to execute or to show results) is not worth doing. Small arbitrary quality improvements in different parts of the system are not worth doing.

I want there to be a domain/vertical where this does not hold.

Can you direct me to the underlying data for this?

https://customers.ai/articles/employee-tenure-in-tech-compan...

But google around, this number is well known within the inustry.

In the years I was at Google I only saw a few people leave in my and adjacent teams, if average was to leave after 1.5 years I should have churned through several generations but the people I worked with early were mostly there when I left but there were several times more people overall.

As a product succeeds and establishes lockin, management may decide that devoting resources to improving the product's design has less relative ROI than devoting those resources to targeting new users who are not locked in. Those new users may be in an adjacent market that needs new features, which is typical when a product started in an intentionally narrow niche. New features crowd out the designs for old market users -- it's hard to stuff 10lb of shit in a 5lb bag -- and as the senior PMs & designers move to the new growth areas, more junior ones sub in to the old ones, and struggle even more.

It takes a LOT of design & product discipline & effort to avoid this. I think that's generally a disaster for consumer products, but in enterprise, which often pays for everyone else, the issue is much less clear, and especially on time scales that matter to individual employees. I'm always impressed when companies escape these kind of disincentive structures!

Doctorow is right and it basically all comes down to competition. Internal politics or internal anything aren't really the pivotal factor in product quality. To understand this you have to look at the market not just one company in it. If Company X has a lot of competition and product quality is required to beat them, it'll inevitably improve its quality or die. But put that same company in a situation where they have no effective competitors and it's virtually guaranteed that product quality will start to slip.

Stuff like "oh they have good engineers and give them the time to make stuff better" is an effect not a cause. Competitive marketplace -> investment in R&D -> higher quality products.

People will disagree with me but Jira is getting a lot better lately and I’m convinced it’s due to competition that popped up because Jira sucked so much.

The challenge is going back to a mode of building a good product again. Not only do you have to notice that you’re losing and be willing to invest again, you have to kick out all the extractors and convince the craftspeople to come work on a product that they all think is a piece of shit.

Frustratingly, well-designed competition isn't necessarily enough, especially for b2b. Even when there is a challenger, that mostly impacts new customers. For locked in ones, renewal cycles and implementation burden may make it more 6-10 year levels to even be a serious conversation as long one as the legacy product functions. There are only so many Global 10K's, and that's a good chunk of the b2b user population.

An interesting way to avoid the trap is 'mission focus'. If a company culture is mission-focused -- which is often easier in founder-led scenarios -- then decisions come from more than these $ reactions.

All of the telemetry collected is about "crashes" and "what user does". Nobody cares about reducing memory use, increasing speed, etc. unless they give a tangible boost, or more precisely, boosts their bottom line.

There are stories from Microsoft engineers who are berated for improving Windows Kernel, because it works well enough, and being faster is not important. Again, there are stories from the same company saying that first finished implementation of a design among the competing ones is merged into the code.

I have been in cases where I ordered to make it work, and to not care about anything else, and no, I won't have the time to make it better. Luckily, that's a past life now.

All business cares is having "non-whiny" customers, and having tons of behavioral telemetry so they can make "informed decisions" about what to build next. So they can keep their customers paying. That's all.

I made a bug report to a company about one of their features. They acknowledged it, gave me a timeline (very nice, isn't it). After two weeks, I got a mail saying that my bug report is demoted to "wishlist/maybe someday". It was a small thing, but was important for me. So, I changed platforms.

As long as money is flowing, customers are not revolting en-masse, and the product is not built by an "by engineers, for engineers" company, quality is not a concern. Only bottom line is. Regardless of you pay, or not.

Also, Nobody Ever Gets Credit for Fixing Problems that Never Happened [0]. Because the lack of quality is not a problem to begin with.

[0]: https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_....

Well I think they can still get a lot shittier, but no. Eventually the "I could run an instance for myself and my neighbors and it would be better than this" line will dip below the enshittification trend line.

Meanwhile, people are working on ways to avoid having their work be shackled to something that's destined to become less trustworthy over time (the critical dependency varies, but it's usually in there somewhere, it's wherever you get your "moat" from). So there's hope. The replacements have a chance at escaping the cycle.

We gotta stop building things that control people and start building them because we actually want the outcomes that they make possible. Until we do that, the enshittification will continue.

Same with "good" architectures, "quality" programming languages, "good" tests etc. etc.

"Quality" and especially the prioritization of "Quality" tasks is highly subjective in my experience.

In the first scenario, it is clear that for someone with a technical background, communicating the importance of quality is challenging. However, the concept of technical debt facilitates this communication. The notion of debt, with its inherent borrowing mechanism that incurs repayment over time, is something everyone can grasp. In practice, neglecting technical issues increases the cost of changes in the system. Asserting that a feature that takes 15 days to develop could have been done in significantly less time and at a fraction of the cost if the technical debt had been addressed is an argument that resonates with everyone, including those at the highest levels of the hierarchy.

In the second scenario, the concept of product debt is not widely discussed. At best, discussions around Return on Investment (ROI) occur at the inception of product development, focusing on creating a Minimum Viable Product (MVP).

Should we then treat a product as an asset, considering its cost, profitability, and how changes (such as new features) affect these aspects? Is there literature on this topic?

From my experience, companies have difficulty grasping the product role (the role of Product Owner often obscures the issue). Just this week, I was explaining to my client that the product should not be defined by the sales team and that the individual in the product role must have direct conversations with customers.

PS. Big fan of this person’s recent blog posts. He’s been on a roll!

Otherwise the scope will grow exponentially no matter how big is your company you won’t be able to fix all the defects.

There's no such thing as 100% quality in engineering. Never has been, never will be. Engineering is about delivering requirements, on-time, and on-budget. Trying to deliver more than the requirements either impacts budget or it impacts delivery time, every time, and the requirements are poorly defined to begin with.

The way you swim against this tide isn't by shaking your head at the idiocy of whoever you inherited the code from - it's by setting a positive example for your teammates, mentoring them, helping them grow, trying to raise the bar a little bit on every code review before everyone's patience runs out and you have to merge in what you got. Help everybody make the best of the time they get to put into the project, instead of living in some fantasy land where you can polish forever and never deliver.

Nothing you said after that matches this statement.

I switched majors from Computer Science to Computer Engineering because engineering was about dealing with real-world constraints so that we could make an actual difference in the real world. I got the MBA because I understood that the "constraints", i.e. the budget for the project, is only meaningful within the context of how much revenue the system brings in, i.e. how do you build systems that are long-term maintainable because they bring in the revenue to pay for salaries for engineers to maintain them.

So yeah, I have an MBA, and I care about long-term maintenance. I care about quality, and I care about delivering on-time and on-budget. I don't see an inherent contradiction between these aims. Half the value of the MBA was in helping me realize how much scope ought to be reduced so that the system can be delivered on-time and on-budget while not compromising on quality of what remains in scope. But more to the point - this only assumes that you have "perfect" engineers doing perfect work to begin with. In reality, your bottleneck is usually the people working on the system. Very few places are swimming in a proverbial ocean of 10x engineers. So engineers who care about quality would do better to focus on the actual bottleneck for quality and build up their peers instead of tearing them down.

I spent a lot of time minimizing bugs and I choose deliberately to have less features and focus ond speed aan reliability.

But website visitors only see that a competing product has 2x the features (at great cost).

I have a customer with 10 million end users, in one year they have reported only 2 bugs, both bugs fixed within a day.

It's also hard to sell another 12 months of support this way, as it "just works". Bugs and imperfection can actually be a way for users to "bond" with your product.

Another downside is that the product does not have a weekly update cycle, as there is not much to fix.

People on github might think the project is dead. In reality, i spent a long time working on the product foundation, but that has no face value.

Do you have a product yourself?

Reach out to me at robbert@datagridxl.com.

It's not really possible to say code quality is down 20% this week though.

Given enough time, there will be an open source version of every kind of software, leading to commodification of the most important stuff.

This is why selling compilers used to be a major business, and now simply doesn't happen at all. It will happen to AI. It is currently happening to game engines.

This actually leads to more bloat, not less as the foundation for new products is built on larger and larger stack of FOSS dependencies.

So what is big tech? Big tech is a handful of monopolies that derive value from network effects. If you want to develop great software, contribute to open source. If you want to make big money, join a monopoly.

If you want the best of both worlds, find yourself a niche in a monopoly developing FOSS :)

This ‘word’ has no etymological roots and cannot be taught to kids/teenagers or placed in the dictionary/thesaurus (most likely placed under the vulgar section if it has one) or cannot be said on tv or radio (some stations and channels have a policy that prohibits strong language being said over the airwaves)

There has to be a better word than this before we can just make up words that contains strong language without thinking about it.

The other suggested phrase I see in this thread is “management decay,” but I don’t like it. Decay is a natural process. Here, the “en” at the front indicates an intentional, active process.

If you want something less crude, maybe we can count a phrase like “platform arson.” But I think people relate to the vulgarity.

Not a qualm I have with saying it to my own teenager.

"or placed in the dictionary/thesaurus"

There are far worse words in every dictionary - sexual and scatological words, racial and other slurs. I did not even know that "vulgar sections" in dictionaries were a thing. It sounds like weirdly puritanical idea.

It is also a word that is getting less offensive - the general trend is towards slurs being more offensive. It has got to the point where the FT can put the word in a title, it has got to be pretty widely acceptable: https://www.ft.com/content/6fb1602d-a08b-4a8c-bac0-047b7d64a...

(From https://news.ycombinator.com/item?id=39489675)

Huh? Not only does it have them, they are extremely transparent since it's such a recent coinage.

https://www.etymonline.com/word/en-

https://www.etymonline.com/word/-fy

Like, you appear to be using these words in a nonstandard way; I'm not sure why you expect anyone to know what you're talking about as a result. I would suggest defining your terms if you want to be clear.

I mean sure it's a pretty dumb word and hardly the one I'd use. But you're seemingly talking nonsense about etymology.

[0] Note that "etymology" is often used to mean "known etymology", so in that sense a word can have no etymology, but that's not what I mean here.

Well, I wouldn't wonder about a hypothetical -ifiation, because that would have involved a perceived need to derive a verb in -ate from a verb in -fy, and the English -ate derivational suffix producing verbs doesn't really provide any semantics, so there's no point in applying it to something that's already a verb.

But you do raise a good point about -fication in general; I would expect the form to be -faction, as indeed it is in liquefaction and putrefaction. (Or -fection, as it is in perfection and confection.)

This is because the -io(n) suffix is applied to the stem of the fourth principle part of a Latin verb, and the fourth principle part of facio is factum, not *ficatum. We see many words in -ation because many Latin verbs use the regular fourth principle part stem ending of -at-, and when you combine -io(n) onto that you get -atio(n). But we shouldn't see anything in -ication.

I note that etymonline observes that petrification is "etymologically better than the more common petrifaction". This is interesting for two reasons; first, it must be many decades out of date (at least), and second, it states that the form in -fication is to be preferred to -faction. It also (under the entry for petrify) traces this to a Latin verb petrificare, but wiktionary (generally more up to date) mentions no such verb and attributes the form petrification to a formation in French.

The fact that the combining form of facio, facere in Latin is -ficio, -ficere makes me suspicious of etymonline's description of "-ficare" as "the combining form of facere".

Nobody would be complaining if some milquetoast word was coined, and hadn’t got anyone’s attention. But that wouldn’t be better.

I also happen to appreciate that the word’s undesirable connotations fit the undesirable situation it refers to perfectly.

We can stop meeting in the streets, pointing our pointy fingers at big tech, and shouting “Enshittifier!” and retire the term, when they stop. Or they get stopped.

in the meantime, let’s pull together to get some more helpful terms into Webster’s … Googlebleck, Debasebook, Amageddazon, Intuitwit, Oriful, along with pre-existing Crapple (too apropo!) and Microsuck.

The Enshitifenagling DOGMAIC (“Dogma Ick”) Seven. Shame! Shame! (Five more times…)

And I say all this with (sadness and despair, bitterness and humor, and) profound and sincere respect for all the hard work these companies did to lock me in!

(Now can I please haz JIT for Vision...? I now desire to make spacial cubes - no more graphical squares for me - dance fast!)

> Doctorow has used the term platform decay to describe the same concept.

It's a very important and necessary word, apparently.

Often I read an article and that ‘word’ pops up and the article loses credibility, because of this ‘technobabble’ which is worse with purposefully laced vulgarity.

It’s always used in tech circles because it’s ‘funny’ now but we know we cannot say this in a serious discussion in public or context and expecting the other side to take what you’re saying seriously.

You are right to fight it and I believe if more people say this ‘word’ then it gives me the green light to coin words with ‘fuck’ in them and getting the public to say it without questioning me.

That already happened. Look how lightly people take references to "TFA" on this very site.

https://americandialect.org/2023-word-of-the-year-is-enshitt...

I never did take the ADS seriously though, but it would be only about time that this may reach the Oxford English Dictionary.

I guess it's time to coin a new word with a combination of 'fuck', 'shit', etc in it on a new blog and throw it and push it around and expect people to just say it on tv and radio stations.

Edit: I kid, but, do you have a word you’d like used instead?

Some things or situations are inherently complex to handle and you may still want software for them (especially because they are complex). Simple code won't usually handle complex stuff, and you may still need quality.

Now you should reach for simplicity. Which may itself be complex to define.

But never complicated code: crufty fixes upon fixes, too many layers of indirection, templates templating templates; you won't need that to solve complex problems.

I think you are confused about what simple code means.

(but I'm totally happy with isoprophlex's answer actually)

Most any software can be broken down in a modular way so that the units could be understood by a junior and you'd rarely need to think about more than one cluster of interactions at once. Maybe this is naive, but up until now found it to be true - that said, I never worked in rocket science.

While enshittification is certainly real, stock value or company size can't explain it all. Do startups produce shining examples of high-quality code? Not from what I've heard. It's whatever hack gets it working. Google had put a lot of work into cleaning up the messes of the past, and from what I hear from Xooglers has one of the nicest code bases around.

Quality code is hard to write. Code that works for now is pretty easy. Anyone under pressure to produce code quickly will produce crappier code. Which means every startup, every Big Tech company, everything in between, and all the other companies suddenly depending on software.

And then there are us engineers. We get a kick out of making things work, we love starting new projects, we are enamored of the newest framework. But carrying the task through all the way to nice finished products with full test coverage and beautiful code is a slog.

It's easy to blame capitalism, and it has its share of the blame. But we cannot absolve ourselves that easily.

GPs point, I think, is where are these supposed small/medium tech companies with such dedication and success in maintaining quality? This seems like a pretty universal problem across all tech, not anything specific to "big" tech. I'm not sure where you're finding these supposed "high quality" startup products; their offerings are almost universally even worse IME.

Moreover, the personal jab at the end is quite confusing. You might disagree with GPs point, but the "caliber" of their comment seems quite decent, and certainly far higher than your own.

As for the generations, may I have the honour of knowing your age, my friend?

A company with 100k employees will ship crap just by default. And Google is a shining example of that.

Of course, but the most flagrant offenders in this regard are not startups. Insurance, banking, enterprise SaaS, and credit bureaus dominate the field of objectively terrible, buggy, and difficult-to-use software. "Big Tech" (at least referring to the largest american companies) are far from the worst offenders in this regard, which makes me somewhat confused as to what the article has an issue with. Hell from my perspective half the big tech companies are putting out higher quality software than ever!

I think the "how?" question is easier to answer. I'll call the process "software rebranding". Or perhaps pathology is a better word than process. I've rarely seen a corporate rebranding — that is, a name or logo rebranding — that hasn't been a disaster and made the brand worse. Yet corporations continue to rebrand. Likewise, corporations seem to have an almost pathological compulsion to rebrand their software, to reinvent the wheel, fix what isn't broken, change for the sake of change. For whatever reason, they're unwilling to rest on their laurels, leave well enough alone. The situation has become so perverse that corporations now have to force software updates onto unwilling users who dread them. Various methods of hostile trickery are employed to perpetrate the deed, such as hiding the software update mechanisms or pushing annoying notifications that can't be suppressed.

The "why?" question is more difficult. Many commenters are suggesting that software quality doesn't "sell" in a non-competitive environment, e.g., a corporate duopoly. Quality doesn't move the stock price. But I would suggest that "shiny new features" don't move the stock price either in a non-competitive environment. Once a corporation has already captured its market and eliminated the competition, what good are new features? They're a needless expense when you could just milk the large, sticky user base. And as I already mentioned, the user base doesn't even necessarily want the changes. They're often dragged kicking and screaming into the software rebranding.

I'm not sure there is a rational explanation for the phenomenon. The tech industry is prone to trends, ideologies, you might even say religions. Agile, for instance. (I can't be the only person who looks at the image on the manifesto web page and isn't immediately reminded of the birth of Jesus and the "wise men".) Perhaps there's not a single explanation, though. A situation that's complex and widespread usually has compounding causal factors. I'd guess that in the tech industry it's a common feeling, or fear, that "if you're not innovating, you're dead". Even monopolies might be afraid of stopping the hamster wheel of constant change, regardless of whether their fears are founded.

Another suspicion I've had is that software rebranding is due to what I'll call Press Driven Development. If users aren't loving the rebranding, then who does love it? The press. Or rather, the press doesn't even need to love the branding; they could actually hate the rebranding, as long as they cover the rebranding. All press is good press, which is why bad rebrandings continue to occur, according to my theory. Free advertising for crap is better than no advertising for quality. The press has an endless hunger for new content, and corporate rebrandings, whether logo rebrandings or software rebrandings, feed this hunger. It's a mutually pathological relationship between the big tech companies and the tech press. (Can anyone explain why the vastly overhyped Google login page rebranding got so much press recently?)

Related reading : https://www.construction-physics.com/p/a-cycle-of-misery-the...

How much value did their stock price lose since a year ago? I had a look. It's 2 dollars higher than a year ago, a +/- 1% change, which is in the same order of change as its daily variation.

So, unfortunately for the passengers flying on those planes, it is probably going to have to get worse before something improves significantly..