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

You should first establish yourself as a productive member of the team. No one is going to want to hear about how they could do things better from someone who just started. Once you have credibility and maybe some allies you'll want to have some evidence to support any new processes or workflows. Anecdotes about how you did things at other jobs won't carry a lot of weight.

The problem with software development techniques and tools like automated testing and style guides is that while they look like good ideas, and work at some places, there's not a lot of empirical evidence to support claims that automated tests will improve developer productivity or code quality.

Programmers usually perceive any new code base as crap in desperate need of new ideas and tools. It takes a while to get into a code base and really understand it, and by that time some things that seemed terrible or confusing at first will make sense.

Aside from what Flankk suggested about being one with the tribe: while you're waiting for your tribal acceptance card, measure the problem in silence.

The change defect rate (how many percent of your commits are made to fix a problem introduced in an earlier commit) is very easy to sample manually, and gives you an idea of the scale of the problem.

Then you can go to the team and say, "Look, 40 % of the things we do are fixing up problems we created in the first place. With better processes in place, we could free up a lot of bandwidth for things that matter."

Or maybe you find out that you have a change defect rate of only 12 %, and the things you think are important, for some reason, don't matter in this team.

----

Measurements that complement the change defect rate for a fuller picture, according to Forsgren et al.

- Deployment frequency (literally, what's the average time between deployments to production)

- Time to fix (when a problem is first reported, how long does it take on average until the working fix is deployed to production?)

- Lead time (once a developer considers themselves "done" with the code, how long passes until that code is in deployed to production?)

The time to fix and change defect rate measure quality, so these are the ones you probably would focus on. The other two measure speed.

You want to become one with the tribe, wear the same clothing, and dance the same dance. Right now you are the outsider and outsiders are always a threat. If you come in there with your outsider ways you will immediately face resistance and risk not being accepted into the tribe. Once you have shown the other primates you are a trusted member of the group, then you can suggest that they cook the meat before eating it.

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.

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”)

Wait until a bug comes up, fix it, write a test for it, then describe the problem, fix, and test on the next stand-up. Do that a few times and eventually others will catch on without correction or conflict. In short, just raise the bar.

When the team has a demo day, brown bag lunch, or something where people share new ideas, that’s a great time to show off testing.

Are tests part of your CI/CD pipeline now? You can always add them to your own code. And slowly increase the number of tests that way.

You might have a harder time adding a style guide if no one cares. You could try to add the style guide as part of your build pipeline. You might need to start by fixing all the low hanging fruit errors yourself.

Whatever you do, don’t do what I did and start complaining about stuff at every step while in a new job. It’s a big ship. Turn it slowly, or be prepared to live in the worst cabin and/or be thrown overboard.

Bring it up in your 1 on 1 with your manager, too. Just ask their thoughts. Maybe they also feel the same way, and have wanted to improve things.

Is there anything extraordinary about this job? You could always just find another job where testing & code quality are taken more seriously if it’s really important to you. If something is special, be prepared to live with the things you don’t like for a while.

See Chesterton's fence: "The principle that reforms should not be made until the reasoning behind the existing state of affairs is understood." [https://en.wiktionary.org/wiki/Chesterton%27s_fence]

There might not be a particular reason for why things are the way they are. It might have just grown to be this way.

I haven't read it but I've heard good things about "Working effectively with legacy code" by Michael Feathers.

Have you considered that for this business or function within the business, maybe it doesn't matter?

> This must lead to a lot of problems which I'll only face after ramping up, but even onboarding is painful if you don't have e.g. clear automated testing set up.

Maybe you'll learn why this is not the case after several months of working in your new role.

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.

Since you mention a big tech company, what you’ll probably find is that there are people that care about these things around you, and they’re probably doing what they can and could do with support - not necessarily to do work, but also just moral support. (I like to pretend I’m one of those people in the quality space in my area in my big tech company…)

As others mention, be careful trying to change the world (and especially saying bad things about what you see) before you grow your credibility. But ask a few questions in team meetings (or, at something like FB, in workplace groups) about what test or staging or related infrastructure is available as part of ramping up, and that might get people that care to notice you’re a potential ally.

There’s even the (admittedly probably very) small chance that that the team wants to improve here, and doesn’t know how/didn’t have the resources to do better before - either way, you’ll learn more without alienating anyone.

Big tech companies also often offer mobility and culture variety, so keep your eye out for teams that align with what you care about. Learn what they do and how they got started at least - or possibly move there.

(If you’re at FB, feel free to reach out to me - same account name.)

Have you asked why there's no or very little testing happening? Make sure to ask from a few folks at different seniority, including whoever is the Big Kahuna.

The answers should be pretty revealing about the engineering culture at the company. You can then decide what it is that you want to do about it with better information.

You never know, maybe the Big Kahuna tells you you have open mandate to make improvements in the area...stranger things have happened.

In my experience, if you mention to people there's not enough testing, most of them will agree. They've probably been fighting that fight for a long time.

Cut your team some slack. Before you go telling them they're doing it wrong, do better yourself. Make sure your code is well tested. When doing code reviews, request more tests strategically. (Meaning, don't complain that there are no tests. Point out specific tricky or dangerous areas where an extra test could make a difference). If they don't know how, help them.

ASK about current practices ("Hey, is there a style guide I can use to help me get up to speed?"). DON'T tell them you know better. If you make them resent you from the beginning, you'll never make any progress.

Well, how about just doing your work first? If you like writing tests, do it. If you're allowed to commit them, OK. If it is good, others will follow.

But don't talk to much about it and beware forcing others to do their work like you do. If there is something like code review meetings, you may show it to others. If there is no SonarQube or infrastructure, establish it e.g. in Docker on your system. Have a plan in mind, how to transfer it to the company infrastructure, but don't force anyone to do so. Just if someone asks you.

You have an opportunity here to integrate YOUR personal way of testing and spreading the knowledge. Have faith that good things will prevail. Give it a year...

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.

It takes a little time for people to see why testing is important. Since you're new to the organization, tread lightly and keep an eye out for places where testing can really make everyone's life better.

I've found that there are a few key junctures at which people take to testing. Here are some:

1) When dead-simple unit-tests catch old bugs. If cos(0) doesn't return 1, there's a problem.

2) When unit tests, for the first time, catch an important new bug in code they're writing.

3) When there's enough testing coverage that you can rip the guts out of a function, install new guts, run the tests, and be certain that everything is fine.

4) When good coverage newly applied to old code finds really subtle very old bugs in code everyone trusts.

Use the easiest-to-use unit-testing library you can. If there's no test-coverage today, some testing is worlds better than no testing. Once people can see for themselves how helpful it can be, the organization can get fancier if it needs to do so. I absolutely love GNU Octave's testing framework [1], as the syntax is as simple as

  function r = foo(x)
     r = x+2
  end

  %!assert (foo(3) == 5)

When it's easy, people take to it like water. I perpetually emphasize to students the importance of writing the most-boring/simple test first.

[1] https://wiki.octave.org/Tests

You’re not going to convince people to change their views with words alone as a new team member.

Just do what you need to do in order to be productive. If that means writing tests, do it. It doesn’t matter if there’s CI in place. Maybe only you run the tests on your local machine occasionally. Just do it. Testing is a part of software engineering and you don’t have to ask permission to do your job.

This is tough. It all begins with the person leading the team. Even as CEO, I had a tough time convincing my CTO to do this. There are only two ways I see this could change - either the leadership changes or something drastic happens which forces them to understand the importance of this. Mostly the former is what is going to pan out IMO. People rarely change

Unless you've been brought in as leadership to turn things around, better to run far and fast. Working without sufficient tests is, from my experience, the easiest way to get 1 month of work done in 6. This will also affect your personal skills development and your outlook on how effective teams work. Get out before it infects you too.

I enforced it via code review, but this worked because I lead by example by seeding the entire project as the architect. However, my mandate for 100% code coverage eroded over time because people are either lazy or just not smart enough. Here is the thing, that's ok because when the shit hits the fan then it will be their responsibility to stand and explain why their shit code caused an issue.

Practice what you preach and ship excellence and if you do it well with good management then you'll be able to shape the team. Otherwise, good luck because we have yet to iron out what good quality even means.

You join a team/company that values tests and code quality. Should be a part of you interviewing the company. Trying to single handedly change the culture of a large company where you'll have few allies (because by this point, they'll have all self selected away) is a fools errand.

One general strategy is to make a suggestion, allow it to be shot down, then start gathering data about why fixing the thing would help.

I operate at a very high level in an organization but in general I accept disagreement, keep track of what the outcome was, and if I was right decide if I want to revisit the issue with the new data. The best outcome is I was wrong and nothing needs to change, or second that I was right but the impact was small so the effort was unjustified. If it turns out I was seriously right, then we can start putting motions in place to fix the issue, and I get credit for voicing concern early. I hope to be wrong!

Thanks everyone, great advice.

For all those saying "get a new job": not that simple. Immigration. If things are real shitty (which they aren't!), I'll get a new job anyway and move back home. But I'd rather not.

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.

Do it for yourself first. Make a style guide and follow it, and setup an automated formatter that will implement that, and apply it to your own code.

Write tests for things that you work on.

If it’s valuable, and you are a productive team member, you will eventually be able to convince other to adopt your practices.

The best way to convince people to test is to show its valuable by finding/preventing bugs.

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

Related question - how do you convince small teams (15 eng) QA, test and code quality matter?

Find a new job. Don't try to fix cultures, you can't.