3 ms·

I get what you're saying, but... Logging is not auditing, AFAIK. Also, and I may be very wrong based on the way that org prepared tasks, he may have been signa

I get what you're saying, but... Logging is not auditing, AFAIK. Also, and I may be very wrong based on the way that org prepared tasks, he may have been signaling scope creep... If it's not in the task, you don't do it. If you think it should be done, you backlog it...

AckRite 3y ago
I agree with the comment above yours but also feel that this is... different style of work? Or attitude? Not sure how to name it but feels like I also brushed up against this numerous times. I assume that line of "what is scope creep and what is assumed to be in scope even if not written down" has to be blurry but I tend to judge people on which side they end up on, because I feel it correlates to indifference etc. Ultimately, it feels like a bad approach to work relationships - you actually have to do personal groundwork in your team to unblur the line to where you and your team agrees. And if that doesn't work out - leaving is a valid, if sad, option.
withinboredom 3y ago
Not to be pedantic, but it's called an "Audit Log", usually. So, it is logging, though if you don't keep your logs forever, it is usually logged to a db or something (but that isn't necessary -- depends on the industry, privacy policy, etc.). > If it's not in the task, you don't do it. If you think it should be done, you backlog it... You shouldn't have to be told to do your job. One day, someone is going to ask why X wasn't done (when it clearly should have been, by all industry standards, and especially when it is exactly one line of code) and "I was just following orders" doesn't work in any court, including the ones that get you fired. When implementing auth, almost no PM is going to write down "mitigates timing attacks" as part of the acceptance criteria, but you do it anyway because it is the right way to do it.
- pixl97 3y ago
  And none of those things come down to the individual dev in any sizable organization I've ever seen. Suddenly you've started adding a db schema new db schema to the requirements and are likely blowing up the sprint. You push the ticker back up and fire off a few email to PM and ask what the hell they are doing with the requirements
  - withinboredom 3y ago
    Who said anything about db schemas? What are you talking about?
    - pixl97 3y ago
      Where you throwing your audit data? Kibana?
      - withinboredom 3y ago
        That's an implementation detail so far from what we're talking about that its almost nonsense. Even if you don't have any infrastructure at all, simply injecting a NullLogger and audit logging to it is better than nothing at all (and filing a ticket to address that ASAP). That's two lines of code, but what I was talking about was exactly one line of code because the infrastructure already existed.
phatskat 3y ago
> he may have been signaling scope creep... If it's not in the task, you don't do it. If you think it should be done, you backlog it... Correct. Especially if you’re working for a client that’s billing by hour. Regardless, new work changes scope and blah blah agile. Yes it’s overhead, and it also creates a chain of who did what, and when.
- withinboredom 3y ago
  I fail to see how adding "$this->auditLog->info('user logged in', $details)" is scope creep. Maybe you can help me out? This is no different than suggesting a change in the code (in PHP) from: $password === $expectedPassword; to hash_equals($expectedPassword, $password); where the hash_equals function is a timing-attack resistant comparison.

AckRite 3y ago

I agree with the comment above yours but also feel that this is... different style of work? Or attitude? Not sure how to name it but feels like I also brushed up against this numerous times. I assume that line of "what is scope creep and what is assumed to be in scope even if not written down" has to be blurry but I tend to judge people on which side they end up on, because I feel it correlates to indifference etc. Ultimately, it feels like a bad approach to work relationships - you actually have to do personal groundwork in your team to unblur the line to where you and your team agrees. And if that doesn't work out - leaving is a valid, if sad, option.

withinboredom 3y ago

Not to be pedantic, but it's called an "Audit Log", usually. So, it is logging, though if you don't keep your logs forever, it is usually logged to a db or something (but that isn't necessary -- depends on the industry, privacy policy, etc.). > If it's not in the task, you don't do it. If you think it should be done, you backlog it... You shouldn't have to be told to do your job. One day, someone is going to ask why X wasn't done (when it clearly should have been, by all industry standards, and especially when it is exactly one line of code) and "I was just following orders" doesn't work in any court, including the ones that get you fired. When implementing auth, almost no PM is going to write down "mitigates timing attacks" as part of the acceptance criteria, but you do it anyway because it is the right way to do it.

pixl97 3y ago
And none of those things come down to the individual dev in any sizable organization I've ever seen. Suddenly you've started adding a db schema new db schema to the requirements and are likely blowing up the sprint. You push the ticker back up and fire off a few email to PM and ask what the hell they are doing with the requirements
- withinboredom 3y ago
  Who said anything about db schemas? What are you talking about?
  - pixl97 3y ago
    Where you throwing your audit data? Kibana?
    - withinboredom 3y ago
      That's an implementation detail so far from what we're talking about that its almost nonsense. Even if you don't have any infrastructure at all, simply injecting a NullLogger and audit logging to it is better than nothing at all (and filing a ticket to address that ASAP). That's two lines of code, but what I was talking about was exactly one line of code because the infrastructure already existed.

phatskat 3y ago

> he may have been signaling scope creep... If it's not in the task, you don't do it. If you think it should be done, you backlog it... Correct. Especially if you’re working for a client that’s billing by hour. Regardless, new work changes scope and blah blah agile. Yes it’s overhead, and it also creates a chain of who did what, and when.

withinboredom 3y ago
I fail to see how adding "$this->auditLog->info('user logged in', $details)" is scope creep. Maybe you can help me out? This is no different than suggesting a change in the code (in PHP) from: $password === $expectedPassword; to hash_equals($expectedPassword, $password); where the hash_equals function is a timing-attack resistant comparison.