Ask HN: How to convince big tech team that tests and code quality matter?

Just quit and move on. If they're that petty on what is industry standard, then they're going to be petty on other things as well. Also if the other developers are okay with not writing unit tests too, then it's a shit job.

But if you want to try, measure downtime or loss of productivity. Then convert it to dollars assuming average rate of dollars in the industry. And put the dollars in parenthesis ($10,000) to denote the loss.

Write an email, forward it up the chain. Then when the next outage happens, gently point out that email, and be prepared to offer solutions.

While almost every process can be improved, you've either made a big mistake or want to make one.

If they're suffering the dire consequences that you predict, the mistake that you've made is joining the team. Newcomers can't fix systemic problems unless the organization actually wants said problems fixed AND said newcomers are tasked with fixing said problems. Even then, odds are against success.

If they are shipping reasonable product, then they're not suffering said dire consequences. (You did check whether they ship before you joined, right?)

In that case, you're fairly ignorant about some key aspects of the company and how it works.

Such ignorance is a bad basis for suggesting change, no matter how good said change might be.

If I would be your team member my response would be "STFU and finish your task(s)".

I'm replying to this and also some of the sibling comments.

No, automated development-time tests do not necessarily equate to higher quality, given that they:

- Take time away from other activities

- May provide a false positive, lulling developers into a false sense of confidence

- Increase the time taken for certain CI/CD operations, sometimes by hours or days!

- The presence of a large volume of "test" code means that certain refactoring operations take a lot longer, which is a real cost.

People go into some work environments where tests DID help, and they generalise that to ALL work environments.

Automated build-time tests are less important, and entire categories may be potentially unnecessary when:

- The product is written in a strongly-typed language that catches most errors at compile time.

- If high-level "linting" tools are used to further enhance the code quality before the executable ever runs.

- If feedback from the production environment is more relevant. E.g.: for web applications with performance issues being monitored by an APM, but no critical code stability concerns at build time. Think typical web apps with no real consequences to a crash, not finance applications where a small error could mean Real Money.

- Where time-to-market is more important than chasing 100% robustness at the expense of meeting release dates.

You often see people from a PHP or Python background go on and on about the importance of tests, but those are dynamically typed languages with lots of unexpected pitfalls that only testing will uncover. Meanwhile entire teams do just fine without any automated tests when using languages like C#, Java, or Rust.