Live data from Hacker News

Quality is a hard sell in big tech

pcloadletter.dev

91–100 of 165 posts

Re: Quality is a hard sell in big tech

#91

That's not a problém of big tech, of tech or any other field. That's a problém of our society where the main goal is to make as múch money as possible. Any talk about quality is either marketing or practically useless compliance for some arbitrary certificates. There is no incentive to produce "quality" (for a meaningful definition of quality).

You seem to parrot a take that is popular these days in western internet ("cApiTaliSm bAd!!1"), but let me tell you as someone born in USSR that quality of everything starting from simple things (shoes, etc.) to complex things (cars) was atrocious. The problem with modern software quality is very simple - no one is going to buy stable and polished iPhone app for 500$ when there is bunch of similar apps that may have some bugs and even crash once a week but cost 5$ (or even better cost 0$ and contain ads).

Re: Quality is a hard sell in big tech

#92
post #52

Earlier quoted context omitted.

> Do startups produce shining examples of high-quality code? Presumably this is about the quality of the end software, not the code that feeds it. some classes of startups are certainly known for attempting to improve quality apparent to the end-user over market leaders. Some even succeed. For the most part this isn't hard compared to "big tech"—just strip out the enterprise-oriented crap and ads. The hard part of ma…

The list in the article lists more code quality issues than user visible issues. And frankly, bugs and UI flakiness are everywhere.

> And frankly, bugs and UI flakiness are everywhere.

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!

Re: Quality is a hard sell in big tech

#93
As an engineer who cares deeply about quality as an ethical imperative - save it for your hobby projects.

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.

Re: Quality is a hard sell in big tech

#94

Earlier quoted context omitted.

It's a silly coinage to describe a concept that has little to no roots other than 'shittification' which isn't really a word (other than the laced vulgarity), so I don't accept this either, so this is rounded to 0. I do not see it as a serious 'word' to be written, taught or spoken, in fact using this 'word' gives the article less credibility as it makes the article trite and childish.

I'm not sure what you think "etymology" or a "root" is. The word is quite regularly formed via English derivational morphology. Start with "shit", which -- like every word that isn't a pure coinage -- has an etymology[0], going back to the (hypothesized) Proto-Indo European root "skei-" (it's cognate with "scissors"!). Then it's just combined with the well-known affixes "en-" and "-ification", each of which has a his…

> have you ever wondered why there's a "c" there in that suffix instead of the more regular "-ifiation" that would result from directly combining "-ify" and "-ation"?

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".

Re: Quality is a hard sell in big tech

#95
post #7

Earlier quoted context omitted.

There's more to quality code is simple code. 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.

> Simple code won't usually handle complex stuff I think you are confused about what simple code means.

Enlighten me with your definitive and universal definition of simple code then :-)

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

Re: Quality is a hard sell in big tech

#96
post #66

Quality is a hard sell when it's not measurable. If it were measurable it'd be easier. It's not really possible to say code quality is down 20% this week though.

The problem with that is that the only practical measure of code quality is future costs. Which by definition haven't happened yet, so aren't measurable. And once they have happened you don't know what they could have been instead so it's hard to attribute them.

Re: Quality is a hard sell in big tech

#97

That's not a problém of big tech, of tech or any other field. That's a problém of our society where the main goal is to make as múch money as possible. Any talk about quality is either marketing or practically useless compliance for some arbitrary certificates. There is no incentive to produce "quality" (for a meaningful definition of quality).

You seem to parrot a take that is popular these days in western internet ("cApiTaliSm bAd!!1"), but let me tell you as someone born in USSR that quality of everything starting from simple things (shoes, etc.) to complex things (cars) was atrocious. The problem with modern software quality is very simple - no one is going to buy stable and polished iPhone app for 500$ when there is bunch of similar apps that may have…

Capitalism and Authoritarian State-Capitalism can both be bad.

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

Re: Quality is a hard sell in big tech

#98
I understand the issues at hand, and it seems to me that they should be divided into two categories: technical problems on one hand and product-related issues on the other, as defined by Eric Ries in "Lean Startup."

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.

Post reply on HN