[cgearhart]

I think there’s often a misalignment of incentives when annual perf reviews are judged on feature work delivered not quality. Engineers who spend any time polishing or finding and fixing bugs wind up rated mid, while folks who quickly crank out mediocre or bad code that does something new are on a fast track for promotion. This creates a current in the whole org where PMs, engineers, managers, etc., are all focused on new things all the time. Any quality work has to accompany a new feature proposal for traction, and the quality items in that project will never get cross functional support like the new feature work does.

This resource allocation strategy seems rational though. We could consume all available resources endlessly polishing things and never get anything new shipped.

Honestly it seems like the another typical example of the “cost center” vs “revenue center” problem. How much should we spend on quality? It’s hard to tell up front. You don’t want to spend any more than the minimum to prevent whatever negative outcomes you think poor quality can cause. Is there any actual $ increase from building higher quality software than “acceptable”?

[razoorka]

I would prefer to pay 20% more for product which works perfectly, than for product which almost works. But no one asked me.

[OutOfHere]

You shouldn't, because that 20% more will not go to the engineers; it will go to parasitic management. Money is better if paid for services than for software. I would find well-maintained open source software instead, perhaps contribute to one, or put in the effort to develop one.

[Thorrez]

If I'm choosing between 2 products on the market, if I pay for the higher quality product, that's going to increase that company's revenue. That will either allow them to pay the existing engineers more, or hire more engineers. The lower quality product won't get my revenue, and thus won't be able to do that.

More revenue -> company grows

Less revenue -> company shrinks

[OutOfHere]

Open source software has no revenue at all, yet it often is superior in many ways.

[Thorrez]

That's a different situation from what this conversation was about. The conversation was about if there are 2 for-profit products, one costing 20% more than the other, would paying for the more expensive one provide money to engineers or not.

Regarding the new conversation topic: some open source software does have revenue. Forms of revenue include: donations, selling support, selling licenses that are less restrictive than the original open source license, ads, and selling addons. Yes, revenue for open source software is generally less than for-profit software, and despite that the open source software is often higher quality. I didn't claim that a higher quality product will always have more revenue than a lower quality product. I just made a claim about where the money goes.

[OutOfHere]

I think we're getting somewhere now. The solution could be to fund the developers of open source software, actively paying them to implement the desired features that otherwise don't get picked up (while maintaining good quality and their continued ownership over the software). Micromanaging them as employees wouldn't work.

[brazukadev]

it is the same conversation: quality software. Revenue/pricing are NOT the main signals of software quality at all.

[godelski]

I'm not sure this really matters at this point. It's like filming yourself giving food to the homeless. Is it better if you didn't? Yeah, probably. But at the end of the day does that person have food when otherwise they wouldn't? Also yeah.

I'd rather take a step in the right direction than none at all. If the management can be convinced that there's more money to be made this way then that gives us engineers more power to convince them to solve other such problems. If they care about quality then that gives us back negotiating power. You don't outsource to a third world software mill or AI when your concern is quality. But you do when you were trying to sell the cheapest piece of shit that people will still buy. So yeah, I'm okay with this

[OutOfHere]

You can be okay with it, but it's not going to solve the problem. Management will fix the issue, then soon revert to enshittification and exploitation, so your next major issue will stay unfixed. In the best case, your software will become an annual subscription where you've to keep paying an obscene amount for no new features at all. Overall, it would be a step in the right direction, but only a single step.

> You don't outsource to a third world software mill or AI when your concern is quality.

That's a disastrously fallacious set of presuppositions. A good engineer will use AI well to improve their software, whereas a bad engineer will use it to produce junk.

[godelski]

  > but it's not going to solve the problem

I believe I explicitly stated just as much.

I want to stress that this is a highly complex problem that needs to be solved and that means we need to break it down into smaller manageable tasks. You're not going to change everything overnight, a single person won't change things, nor will a single action change things. There's no clear definitive objective that needs to be solved to sole this problem. Nor is there a magic wizard in the tower that needs to be defeated.

In other words, I gave you my explanation for why I think this can be a step in the right direction (in a sister comment I said even more if you want to read that). But you have complained and given no alternative. Your only critique is that it does not solve the problem in one fell swoop. That was never an assumption I made, it is not a reasonable assumption to make (as you yourself are noting), and I explicitly said it is not an assumption being made. Do not invent problems to win an argument. All you've done is attempt to turn a conversation into an argument.

  > it would be a step in the right direction, but only a single step.

So don't stop after one step.

  > That's a disastrously fallacious set of presuppositions.

Read more carefully. I did not say "use AI" I said "outsource to AI". There is a huge difference in these two things.

Do we need to fight or can we actually have a discussion to help figure out this problem together? You do not need agree with me, contention can be beneficial to the process, but you do need to listen. I have no interest in fighting, so I'll leave the choice to you.

[godelski]

  > I would prefer to pay 20% more

That's the problem with lemon markets though. They are a feedback loop and usually dependent on asymmetric information.

As a simple version think about it this way: if a customer can't tell the difference in quality at time of purchase then the only signal they have is price.

I think even here on HN if we're being honest with ourselves it's hard to tell quality prior to purchase. Let alone the average nontechnical person. It's crazy hard to evaluate software even hands on. How much effort you need you put in these days. The difficulty of differentiating sponsored "reviews" from legitimate ones. Even all the fake reviews or how Amazon allows changing a product and inheriting the reviews of the old product.

No one asks you because all the sellers rely too heavily on their metrics. It's not just AI people treat like black boxes, it's algorithms and metrics in general. But you can't use any of that effectively without context.

At engineers I think we should be a bit more grumpy. Our job is to find problems and fix them. Be grumpy to find them. Don't let the little things slip because even though a papercut isn't a big deal, a thousand is. Go in and fix bugs without being asked to. Push back against managers who don't understand. You're the technical expert, not them (even if they were once an engineer, those skills atrophy and you get disconnected from a system when you aren't actively working on it). Don't let them make you make arguments about some made up monetary value for a feature or a fix. It's managements job to worry about money and our job to worry about the product. There needs to be a healthy adversarial process here. When push comes to shove, we should prioritize the product over the profit while they should do the opposite. This contention is a feature, not a bug. Because if we always prioritize profits, well, that's a race to the bottom. It kills innovation. It asks "what's the shittiest cheapest thing we can sell but people will still buy". It enables selling hype rather than selling products. So please, be a grumpy engineer. It's in the best interest of the company. Maybe not for the quarter, but it is for the year and the decade. (You don't need to be an asshole or even fight with your boss. Simply raising concerns about foreseeable bugs can be a great place to start. Filling bug reports for errors you find too! Or bugs your friends and family find. Or even help draft them with people like on HN that raise concerns about a product your company works on. Doesn't need to be your specific team, but file the bug report for someone who can't)

And as the techies, we should hold high standards. Others rely on us for recommendations. We need to distill the nuances and communicate better with our nontechnical friends and family.

These won't solve everything but I believe they are actionable, do not require large asks, and can push some progress. Better something than nothing, otherwise there will be no quality boots to buy

https://en.wikipedia.org/wiki/Boots_theory

[razoorka]

Exactly. It's an industry shift, and one person can't reverse it alone. But I disagree with "better something than nothing" when it comes to quality. That's how we normalized catastrophes in the first place. The lemon market problem you described is real—users can't evaluate quality, so price becomes the only signal. But engineers can evaluate quality. We're the ones who should refuse to ship garbage, even if management pushes back. Being grumpy works locally. It won't fix the industry, but it fixes your team. And when enough teams refuse to normalize this, the pattern shifts.

[godelski]

  > Being grumpy works locally. It won't fix the industry, but it fixes your team. And when enough teams refuse to normalize this, the pattern shifts.

I cannot stress this enough. Fixing local problems is a necessary step in fixing large systematic problems. Large systemic problems' greatest ally is momentum and the appearance of being immovable.

We solve big problems by turning them into many small problems. There is no difference here. One step at a time.

[godelski]

This just makes it sound like software engineering hasn't matured yet to realize we're building real world systems. It's still a pretty new field, comparatively, but big companies can't run like startups. They should have groups in them that look like that, but not for most groups