3 ms·

The alternative is a big design upfront?

• withinboredom 3y ago
  Generally, it goes something like this imaginary Slack convo: Me: I think we are getting events from SQS out of order and that’s why we are seeing some weird synchronization issues. What do you think about sending events to the regular queue and a FIFO queue at the same time and comparing them? Team: How would that work? Me: Since we are using a single threaded consumer here, I think we can simply override the transport class and instead of pulling from one queue per transport instance, we set up a feature flag allowing us to pull from two, compare the events and if they are different, alerting us in the logs. Team: Sounds good! You don’t need a full design spec, just agreement from the team on the approach. There won’t be any surprises in the review.
  • thiht 3y ago
    > There won’t be any surprises in the review. There can always be surprises. Sometimes when you see something implemented you can get a « click » as to why another solution would be better. It happens to me regularly both on the receiving and giving end of this and it’s rarely a big deal. Most of the time it happened to me, I could reuse the functional tests I had written and parts of the code anyway. Reworking on something so that it’s better is never a waste of time, and it’s always better to do it before it reaches Prod.
    • withinboredom 3y ago
      Making a suggestion on how to do something better is quite a bit different than saying “this isn’t up to standard. Do not pass go. Do not collect $200” We all see these suggestions. That’s ok, and wanted. But to say “ah, no I think it should be the other way.” [reject] That’s what I was talking about here.