3 ms·
"When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong." I think addresses that point quite nicely?
by jkire 10y ago
"When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong."
I think addresses that point quite nicely?
- mikegerwitz 10y agoSorry, my thoughts stopped short. It does in part. But the collective mistakes of a team aren't a predictor of potential future members of the team. For example, we started hiring "junior" programmers, which increases the skill gap.
- pc86 10y agoSort of, but imagine this scenario: I very rarely have issues in problem space A, but I don't really test for A. Maybe a few here or there but it's a small minority of my tests and the coverage is probably just incidental. I test heavily in problem space B for whatever reason. I get hit by a bus, and you're my replacement. You have no experience with problem space A, so there are few if any tests around that space. All of a sudden the coverage is misleading because we might have 100% coverage or close to it, but the thoroughness isn't there and suddenly releases are less reliable and support ticket volumes increase.
- camelNotation 10y agoNot necessarily. In many firms the turnover rate is significant enough that you have no idea who will be working on your code in six months or so. Unless you are on the sort of team that never changes, you can't really use your past experience as a guide for a future team's strengths/weaknesses.
- emodendroket 10y agoIf your goal is to test every possible scenario now or future I think you'll eventually find it's not realistic.
- nickpsecurity 10y agoIt does if team and their strengths/weaknesses stays the same for the life of the codebase. If it changes, then that property goes away to some degree with missing coverage against someone's weaknesses. Better to have QA cover correctness against whatever would undermine it.