4 ms·

No, i would say that your standards are quite reasonable. I would also say that there are many companies that do not meet those standards. Usually they have n

No, i would say that your standards are quite reasonable. I would also say that there are many companies that do not meet those standards. Usually they have no excuse for doing so, just that no one there knows or most likely just don't care. There are also many companies that go overboard with their code review and tests, get none of the intended gains, produce more slowly than they can, because of an attempt to cater to the lowest denominator. But I suppose if you're going to pick one of two extremes, that would still tend to be the lesser of two evils.

Silhouette 6y ago
There are also many companies that go overboard with their code review and tests, get none of the intended gains, produce more slowly than they can, because of an attempt to cater to the lowest denominator. But I suppose if you're going to pick one of two extremes, that would still tend to be the lesser of two evils. I'm not sure that's necessarily the case. IME, not much will kill both the pace of development and team morale faster than poorly conducted, heavyweight code reviews, but one of the few things that will is a dogmatic requirement to have some unnecessarily high level of code coverage in a test suite where everyone is just writing make-work tests to get the number up.
- planxty 6y ago
  Testing is a skill to learn like anything else. Teams that dogmatically apply any new practice or process without making a genuine effort to learn that thing will never extract value from it. If your team can try, fail, and learn from mistakes, you are in a mature organization. If your team gives up quickly because of fear of dogma or has no strategy for dealing with the challenges of learning new skills, it's unlikely your team will ever extract value from testing until the team culture itself changes.
  - Silhouette 6y ago
    IME, the problem more usually happens because someone in management read a book and thought "I know, we can change our entire development process to do this thing I just heard of and overnight my team will all become 10x developers!" If you've got a team that is genuinely interested in improving and willing to work on new ideas to make the best use of them, both reviews and testing can obviously be very helpful. That's not really the situation I'm talking about above, though.
- jmchuster 6y ago
  I think if we're considering the morale of the engineers, then they would prefer to work in a wild environment rather than an overly rigid one. In a sense, it's fun to write bad code, commit it without consequences, and just watch a report of your LOC go up (the key metric for engineers in this strawman company). I think from the business perspective, they would rather have slow to no changes rather than breaking changes. Presumably there is already a product that makes money, and would continue to do so if kept in a maintenance mode. Layer on poorly applied practices, and you've effectively turned it into that.

Silhouette 6y ago

There are also many companies that go overboard with their code review and tests, get none of the intended gains, produce more slowly than they can, because of an attempt to cater to the lowest denominator. But I suppose if you're going to pick one of two extremes, that would still tend to be the lesser of two evils. I'm not sure that's necessarily the case. IME, not much will kill both the pace of development and team morale faster than poorly conducted, heavyweight code reviews, but one of the few things that will is a dogmatic requirement to have some unnecessarily high level of code coverage in a test suite where everyone is just writing make-work tests to get the number up.

planxty 6y ago
Testing is a skill to learn like anything else. Teams that dogmatically apply any new practice or process without making a genuine effort to learn that thing will never extract value from it. If your team can try, fail, and learn from mistakes, you are in a mature organization. If your team gives up quickly because of fear of dogma or has no strategy for dealing with the challenges of learning new skills, it's unlikely your team will ever extract value from testing until the team culture itself changes.
- Silhouette 6y ago
  IME, the problem more usually happens because someone in management read a book and thought "I know, we can change our entire development process to do this thing I just heard of and overnight my team will all become 10x developers!" If you've got a team that is genuinely interested in improving and willing to work on new ideas to make the best use of them, both reviews and testing can obviously be very helpful. That's not really the situation I'm talking about above, though.
jmchuster 6y ago
I think if we're considering the morale of the engineers, then they would prefer to work in a wild environment rather than an overly rigid one. In a sense, it's fun to write bad code, commit it without consequences, and just watch a report of your LOC go up (the key metric for engineers in this strawman company). I think from the business perspective, they would rather have slow to no changes rather than breaking changes. Presumably there is already a product that makes money, and would continue to do so if kept in a maintenance mode. Layer on poorly applied practices, and you've effectively turned it into that.