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

Types do a great job at assuring you’re getting generally the right kind of data in and out of different functions/methods, but they don’t assure that the program is actually doing the right thing. Strong typing just helps to assure that the program isn’t doing specific categories of the wrong thing (in the same way that Rust and Go make it difficult to write memory-unsafe code). I mean, Go and Rust both have testing capabilities built in. If it wasn’t necessary, why would they do that?

Beyond the most trivial of projects, I can’t think of a single project that I’ve worked on (or even looked at on GitHub) that has weighed the costs and benefits of automated testing and decided it just wasn’t worth it.

> some testing is worlds better than no testing

While it is probably true most of the time, like many things in live, "it depends".

When you are developing some not so well defined functions and everything is on quicksand, tests may just slow your progress, while not really providing useful feedback (i.e.: when you always modify a function and its test in tandem). Ideally you should clarify your requirements, but sometimes the process of producing the code is the refining step

Formal style guidelines and mandatory tests for everything are largely wastes of time and often detrimental to software development.

To elaborate: formal style guides prevent simple things like formatting code in a manner that is easier to read in some cases (“why is this newline here? Why did you column aligned this block of expressions?”), and more insidiously force you to write worse code because they constrict you. Style guidelines should be just that - guidelines and engineers should have the decency to not request stylistic changes during code reviews unless they spot code that is obviously sloppy.

As for tests: insisting on having tests for everything impedes development in the present as well as in the future. More crucially the compulsive desire to have everything testable makes you write worse code as you need to abstract away parts that would simply be function calls or use patterns that obfuscate the code. Some will claim that this results in better designed code, but realistically speaking it just results in more complex code, which is almost always worse. You don’t need to use abstractions everywhere. Developers should focus on making shit work well and not over engineering code because they want to feel smart all the while making rationalizations about testable code and whatnot. I digress though so back to my original point regarding tests: in order for tests to justify their existence they have to test something significant and/or test a module that provides a service (read: hidden behind well defined API, api which you test to ensure that it doesn’t break its “contract”)

I worked on a project with no tests. We had to refactor a specific functionality changing database entities, augmenting algorithms and adding behaviour. Hundreds of possible cases, no way to be tested manually. I refactor all the code to be "testable", I wrote hundreds of tests. I wouldn't have done it without tests. In the same project, a single algorithm had a dozen of parameters, dozens of possible scenarios. An issue occured in prod. Luckily algorithm had over 60 tests, we added a red test, fixed, run all green and we were very confident of the release, same confidence not possible without tests.

I fought exactly this battle for two years on my second team at Facebook. Never got very far TBH. Part of the reason is the "become a member of the tribe first" thing that others have mentioned, but there's a kicker: any variance from the existing attitude about tests will itself tend to make you an Outsider. Here are some suggestions for things you can do to gently and slowly nudge things toward a better place.

  * Make sure your own changes are properly tested.

  * Make sure existing tests are reliable and quick to run, since these are common excuses for not doing more.

  * Develop tooling to make writing tests easier, or to write new kinds of tests. Key word is "new" because that taps into the neophilia that's endemic at these places.

  * Use new techniques to reliably reproduce bugs that are still fresh in people's minds, and to show how this can find related bugs as well.

Don't spend too much time on any of these things, though. That will reduce your recognized "impact" and slow the process of gaining trust from the tech-lead "guardians of culture" who have usually decided (based on a mere 5-10 years' experience at only one company) that their current approach is perfect. Better to maximize that impact and then start promoting change. So, to a large extent, "drink the Kool Aid and shut up" really is the best approach available.