Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 76 posts

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

#61

Post by itsdrewmiller »

throwaway8365 wrote: post #14
gregjor wrote: post #5

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 techni…

Totally agree with all your points except >there's not a lot of empirical evidence to support claims that automated tests will improve developer productivity or code quality. If you'd have said "there aren't any published papers _proving_ this" I would've agreed simply because I do not know if such studies exist or not (they might); but I'd argue that automated tests obviously improve code quality and productivity. A…

Generally speaking "empirical evidence" means "published papers", with a little bit of flex for preprints or trustworthy-but-not-peer-reviewed experimental findings.

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

#62

Post by cweagans »

jiggawatts wrote: post #54
cweagans wrote: post #51

Earlier quoted context omitted.

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…

Conversely, I've actually never seen automated tests "in the wild". Every project I've come across has had zero tests, or close to it. I'm dealing with a migration of a legacy code base right now , today, that could probably use some tests! But even suggesting this is a complete non-starter: The time required to write the tests vastly exceeds the time and budget allocated to the migration project. I'll simply enable…

4 hour tests are a nonstarter, but ponder this: how can you guarantee that bug will never happen again? You can be pretty sure. You can reason about the code that you’re now familiar with and infer (based on your current understanding) that something like that won’t happen again. But you can’t guarantee it.

Some bugs don’t really deserve tests that run all the time - that I’ll grant you. I frequently have tests for stuff like that as a form of documentation for myself down the road. A year from now, will you remember the specific steps you took to fix your case sensitivity bug? I wouldn’t. But my VCS will. Future me will be very grateful if I write a “verify this annoying case sensitivity thing isn’t a problem” script somewhere so that if I’m seeing weird behavior in the future, I can be reasonably sure that it’s a different problem (or that my fix got reverted or overwritten).

I also don’t find a lot of value in unit tests or having 100% code coverage. But that doesn’t invalidate automated testing altogether. I cannot tell you how often tests - even just simple end to end, happy path tests - have saved my ass.

I’m willing to bet that you’re already testing your software manually, right? Like if you change (for the sake of example) a form, you’re probably going to submit that form a few times with different inputs. Somebody else down the road is going to do that too. Why wouldn’t you write down the different inputs you gave so that the next person has them available? Maybe that person doesn’t have the same context that you do. Maybe they just aren’t as thorough as you. Either way though: if you’ve already done the work to figure out how to fully exercise the form, why would you make someone else do that work again?

The next logical step after writing that stuff down is to automate it if for no other reason than to avoid having smart, expensive people sitting around doing data entry when a computer can do it for them.

That seems extremely uncontroversial to me and I have a hard time understanding why someone wouldn’t be on board with that.

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

#63

Post by irvingprime »

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.

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

#64

Post by jaredsohn »

cweagans wrote: post #62
jiggawatts wrote: post #54

Earlier quoted context omitted.

Conversely, I've actually never seen automated tests "in the wild". Every project I've come across has had zero tests, or close to it. I'm dealing with a migration of a legacy code base right now , today, that could probably use some tests! But even suggesting this is a complete non-starter: The time required to write the tests vastly exceeds the time and budget allocated to the migration project. I'll simply enable…

4 hour tests are a nonstarter, but ponder this: how can you guarantee that bug will never happen again? You can be pretty sure. You can reason about the code that you’re now familiar with and infer (based on your current understanding) that something like that won’t happen again. But you can’t guarantee it. Some bugs don’t really deserve tests that run all the time - that I’ll grant you. I frequently have tests for s…

Lot of good reasons above. Another is that if code has solid tests, it makes code review a lot easier / faster, especially if somebody else is modifying your code.

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

#65

Post by toast0 »

hoten wrote: post #47
dboreham wrote: post #29

Earlier quoted context omitted.

This assumes the tests are mostly valid. My experience in recent years has been that they won't be.

Of course I'm assuming useful tests, why wouldn't I? Note I don't claim tests completely solve all productivity or onboarding problems. It's just odd to claim it's somehow ~unclear that automated tests aren't good for productivity. Forget the extremes (over testing, too many unit tests vs integration, potential rigidness): tests done right are productivity multipliers. And that's not a "No True Scotsman" retort becau…

> Of course I'm assuming useful tests, why wouldn't I?

Because useful tests seem pretty hard to have in practice.

Especially when starting testing for a project without tests and a team without testing experience.

Early testing reduces productivity, and the proposed gains may never develop.

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

#66

Post by chris11 »

albertopv wrote: post #57
jiggawatts wrote: post #54

Earlier quoted context omitted.

Conversely, I've actually never seen automated tests "in the wild". Every project I've come across has had zero tests, or close to it. I'm dealing with a migration of a legacy code base right now , today, that could probably use some tests! But even suggesting this is a complete non-starter: The time required to write the tests vastly exceeds the time and budget allocated to the migration project. I'll simply enable…

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 i…

+1. That's one of the first things I look for if I need to refactor something. I want tests to exist to verify refactoring doesn't change functionality.

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

#67

Post by gregjor »

tayo42 wrote: post #23
gregjor wrote: post #5

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 techni…

> No one is going to want to hear about how they could do things better from someone who just started I don't understand why more people don't get this. Like thanks for showing up and implying everyone is incompetent with your suggestions?

Lack of humility kind of plagues our profession.

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

#68

Post by gregjor »

noufalibrahim wrote: post #46
gregjor wrote: post #5

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 techni…

This is an excellent observation. Thank you for making this. A pre requisite for "convincing" a large team is respect from the team. Assuming that it's not a toxic jungle, proven competence over a period of time is a good way of of earning said respect. Once you have that, you can cash it in for attention and people will listen. A more tactical thing is to actually do some work. You said that they don't have a style…

"Show, don't tell" is a good principle. Don't tell the team how they should write better code. Show them an example that you can credibly argue represents improvement. Expect pushback and alternate opinions, don't fall in love with your particular style. Teams can get derailed over very minor things like tabs vs. spaces, so remember the important thing is a consistent style, not a particular style. Automated tests can be useful but don't expect the team to retrofit that, or for everyone to buy into it. You have to show the benefits in that environment.

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

#69

Post by gregjor »

throwaway8365 wrote: post #14
gregjor wrote: post #5

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 techni…

Totally agree with all your points except >there's not a lot of empirical evidence to support claims that automated tests will improve developer productivity or code quality. If you'd have said "there aren't any published papers _proving_ this" I would've agreed simply because I do not know if such studies exist or not (they might); but I'd argue that automated tests obviously improve code quality and productivity. A…

I think you are agreeing with me. There's anecdotal evidence like you offer. It's not necessarily obvious to everyone that automated tests improve code quality or it would be a settled issue (it's not).

In my own career (40+ years) I have worked with automated testing and TDD, and without, and I can't say that TDD "obviously" improves code quality. I know other professional programmers who have that experience. Like everything else in software development it's probably situational and depends on the individuals and the team.

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

#70

Post by gregjor »

hoten wrote: post #47
dboreham wrote: post #29

Earlier quoted context omitted.

This assumes the tests are mostly valid. My experience in recent years has been that they won't be.

Of course I'm assuming useful tests, why wouldn't I? Note I don't claim tests completely solve all productivity or onboarding problems. It's just odd to claim it's somehow ~unclear that automated tests aren't good for productivity. Forget the extremes (over testing, too many unit tests vs integration, potential rigidness): tests done right are productivity multipliers. And that's not a "No True Scotsman" retort becau…

> It's just odd to claim it's somehow ~unclear that automated tests aren't good for productivity.

No it's not, because it is unclear. Where's the actual evidence? How do you even define and measure "productivity" in software development?

My customers define productivity as "Delivered according to spec on time and within budget." That's the only measurement they care about. As hard as it is for programmers to understand beautiful "clean" code and automated tests are generally not stakeholder priorities. Yes, bad code and no testing has a cost that may have to get paid down the road. I think stakeholders understand that software will fall short of perfection.

For a long time the standard practice was unit testing, integration testing, and (if you were lucky) rigorous QA. Plenty of usable software got written that way. There's nothing inherently wrong with TDD and automated testing, and when done right those techniques can reduce the need for more complex testing (integration and QA) and help the team understand what the code is supposed to do. That's not the only way to write good code that works, but it's one way.

The problems of defining, measuring, and improving programmer productivity have been known and discussed since the 1960s. We have a set of fairly vague best practices (also known since the 60s/70s) but there's no silver bullet. The problems with developing non-trivial software in team environments mainly come from communication and team dynamics, not from lack of style guides or automated tests. Every little bit can help, of course, but let's not kid ourselves that TDD and automated testing are magic fairy dust.

Post reply on HN