3 ms·

A lot of "security mindset" comes from this principle as well. In theory, you should have strong barriers everywhere, but we're not to that level of maturity ye

by jerf 5y ago

A lot of "security mindset" comes from this principle as well. In theory, you should have strong barriers everywhere, but we're not to that level of maturity yet. (I still hope to see some successful implementation of "capabilities" like in E or something before my career is over. That's an example of what I'm thinking of as maturity.) In practice you get a long way just by writing some code down, and then thinking How would I break this? Oh, hey, if I put this combination of characters into my decoding routine I'll get up to the SQL command level, oh, if I just assume that a user with no email is an admin and I let users change their email, they can become admin, etc. It isn't theoretically ideal, but it's a lot better than not thinking this way.

bsaul 5y ago
In my experience, TDD has a bit of a similar effect on your perception on a problem. By first designing the test that would make the code fail, then making sure it fails, then create the code to have the test pass, you kind of change the way you think about the original problem, and it sometimes helps.
- named-user 5y ago
  Unit tests only catch known failure modes. TDD only catches assumed known failure modes.
  - jerf 5y ago
    That's not a particularly relevant criticism here. The point is that TDD teaches you to think adversarially about your code all the time. The fact that you are not always successful isn't a very interesting criticism; if you don't think adversarially about your code at all you're even less successful. "Testing can't catch all bugs!" is an objection for another discussion.
  - rileymat2 5y ago
    That’s not true, tests also cover happy path, so you can catch failures you had no idea about for instance when running them in a different environment, with a different os, with a different compiler.
mam4 5y ago
Yes it's called being adversarial and it's the best way to improve something.. by actively looking how to break it

by jerf 5y ago

bsaul 5y ago

In my experience, TDD has a bit of a similar effect on your perception on a problem. By first designing the test that would make the code fail, then making sure it fails, then create the code to have the test pass, you kind of change the way you think about the original problem, and it sometimes helps.

named-user 5y ago
Unit tests only catch known failure modes. TDD only catches assumed known failure modes.
- jerf 5y ago
  That's not a particularly relevant criticism here. The point is that TDD teaches you to think adversarially about your code all the time. The fact that you are not always successful isn't a very interesting criticism; if you don't think adversarially about your code at all you're even less successful. "Testing can't catch all bugs!" is an objection for another discussion.
- rileymat2 5y ago
  That’s not true, tests also cover happy path, so you can catch failures you had no idea about for instance when running them in a different environment, with a different os, with a different compiler.

mam4 5y ago

Yes it's called being adversarial and it's the best way to improve something.. by actively looking how to break it