The User Doesn't Care - But you should

i think there's a good and a bad way to deliver those sorts of lines (or a good/bad way to read them)

like, "Customers don’t care about your testing at all. They care that the product works."

testing is one of the ways you ensure your code works. there are useful ways to interpret this line:

• if the tests have high coverage, and pass, and the product doesn't work, you've still failed
• if you find ways of making your product work other than testing, it's fine
• if your testing doesn't follow formal doctrines, but it still catches the bugs, it's fine

part of the line is "the product works". you still have to achieve that, to satisfy the customer. the line is not literally saying "ship bugs", it's saying "focus on not shipping bugs, rather than your specific test ideology"

then, from the user and business's perspective, "product/feature doesn't exist" is also a bug. i mostly agree that fixing existing bugs takes priority over shipping features, but it's not always a clean separation between bug and (missing) feature

then on the other hand, i've heard some of these lines delivered exactly as the author is complaining about, where it meant "cut corners and ship garbage"

To be honest, people uttering these phrases often strike me as people who don't really care about the user either. As is already pointed out, one of the ways to ensure users get a product that works is to have the things in place in the development process that makes this more likely. Something I mentioned in a comment a few days ago.

I encounter this sentiment also often in scenarios where conveniently the users have no good ways to give feedback about the product and no real usage metrics are in place either.

Then there are a multitude of failure scenarios the user might not see or immediately care about when using the product but do impact them. Security being a prime example, the user doesn't care about your product not being secure at all, until they find their data in a data dump online. Performance might not be perceived as an issue by users until they realize it could be a lot better.

This is such a good point! Taking care with the internals is important, and does, in fact, benefit the user.

I do like this take.

While I don't want to go to the other end of the spectrum, over-engineering, I often wish we move away from the "move fast and break things" mindset. In my experience, it is a plague in the web development world.

I hope that the inflow of bad quality software LLMs are enabling will encourage the users to reward reliable software.

I am slowly turning into the grug brain dev, so it's hard to tell if it's a widespread feeling, but I am exhausted of the "let's add another feature".

We often make the mistake of measuring the cost of software by the 'ship date', never including the maintenance costs it will bring over its lifetime.

"Shouldn't be hard, less than a week to build!" never state the 2 to 4 weeks a year to maintain, fix, extend, update, integrate, document...

I often say something in the same vibe:

The end user doesn't care whether youe software has 100% test coverage, or is written 100% in undocumented assembly with labels like lbl0. They care about correctness, performance and user experience.

But guess what? Software engineering makes it easier to each theye goals, and keep the quality on a good level.

Problem is that path also leads to cargo cult and over-engineering, and I'm definitly guilty of this.

But in the end, we still have to deliver actual value to the user.

Lobste.rs mods: please don't tag this as "vibecoding" because this article now contains the word "AI"

Just suggested adding „vibecoding“…