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

I was using it to mean actual data rather than anecdotes.

The subject of programmer productivity is both much-studied and discussed and very hard to define, measure, and compare. The studies that do have some empirical evidence seem to show that team dynamics and individual programmer personalities have the most dramatic effects, compared to things like programming language, tests, style guides, etc. It's not that consistent styles and automated testing are bad ideas, it's that they don't clearly make a big dent in team productivity in cases where one or a few incompetent (or merely slow) programmers, or one jerk, can derail everyone's productivity.

This I why I emphasized demonstrating a commitment to the team and showing some contributions before criticizing the environment and trying to propose changes. If you want the project to grind to a halt tell your new co-workers they are doing everything wrong. No automated test suite is going to fix that problem.

I was working for a world leading semiconductor company. I was in one of the software groups. I was new to the team. I was surprised that the team did not test the software they were releasing. When I requested if I could setup automated build and test servers, I was flatly told "we don't have time". And the next day 5000(I am not kidding you) static analysis defects were dumped into my lap with a deadline of few days. So I asked, how can one engineer cover 5000 static analysis defects in few days? The reply baffled me. I was told most of the defects have been "resolved", I just need to mark them as "resolved" again. So I asked, if these are already resolved why do they appear in the latest report and why do I have to repeat this again. Even marking a defect resolved needs investigation. The reply was "we have always been doing it this way"! All efforts to automate build, tests and static analysis were shot down. I left the company in less than two years. The other team members got high raises and praises for their "efforts" and the company finally failed to enter the market it was desperately trying to get into.

That is a big company in a nutshell, the management is busy spinning employees so good employees immediately call out BS and leave. So what is left is okayish to not so okay employees. Ultimately the company suffers, but who cares when there are bonuses given without understanding what really is happening in the company.

Personally, I don't have time to spend on solving the same problem twice. I want a guarantee that something isn't going to break again. Yeah, it probably won't break again in the exact same way, but if you're writing your test to cover one narrow failure mode, perhaps it's time to brush up your software QA skills.

You're making a set of assumptions when you write a piece of code, right? All the steps between when you actually submit a form and when the data is saved in your database are assumptions that you're implicitly relying on in order for your application to function. Individually, each of those components can work just fine, but no matter how "boring" they are, your application can still be broken.

For instance:

> a distinct sort was case-insensitive but should have been case-sensitive. It was dropping a few hundred items out of hundreds of millions.

You don't know that it's _going_ to work until you've _tested_ that it works. Right now, it sounds like your testing is almost exclusively manual. That's a valid approach, but it doesn't scale very far (neither in terms of application complexity nor team size and composition nor project age).

> Once the code has been established as working, and strong typing is used end-to-end, why bother testing it over and over?

You've established that it's working as expected _now_. What happens if somebody submits incomplete or malformed or outright malicious data? What happens if somebody opens two copies of your form, fills them both out, and then submits each of them in sequence? Which one should take precedence and does the notion of submitting this particular form more than once even make sense? What happens if your database isn't reachable but you have data that you need to save? What happens if another developer on your team updates the ORM and that includes a change to how data is sanitized on its way into the database that breaks some implicit assumption about how your data is going to be stored?

I hope you have some way to catch that stuff in code review. Syntactic rigor and being a bottleneck in the code review process is only going to get you so far.

Personally, I don't want to be figuring any of that stuff out at 3am when the pager is going off. I want to be confident that the team has solved _and documented_ all of the potential problems that they can think of (in the form of tests).