4 ms·

Perhaps this means I'd have a lot of adapting to do if I were to work at a larger organization, but my first thought was "did they test the code they wrote"? I'

Perhaps this means I'd have a lot of adapting to do if I were to work at a larger organization, but my first thought was "did they test the code they wrote"? I'm not talking about automation or integration testing or any of that. I mean did you try using the thing you just built. It seems to me like it would be immediately obvious there was a problem. I could never ship something as critical as this without seeing with my own eyes that it functions as expected.

doctor_eval 3y ago
But the advertising tracking system is not the thing they just built. That’s the problem. They included a tag that included information that was to be passed to that other system, to indicate that this tweet was billable. Presumably the tag was optional, the tag was just misspelled, so everything appeared to work just fine. It’s the downstream systems that cared about this tag and they were presumably not even running on the dev machine on which the offending code was written. The only thing that could have prevented this was some kind of schema that would have rejected an unknown tag at build time. Hence, typescript.
- rmbyrro 3y ago
  That's one of the main reasons why automated tests exist: to make sure a change in one area is not breaking anything else in the system. I'm not against strong typing. Just saying this is a bad argument in favor of it.
  - doctor_eval 3y ago
    But the comment I was replying to said, > I'm not talking about automation or integration testing or any of that
- mostlysimilar 3y ago
  I see your point but the article says this: > This property was then used when logging visible Tweets that it was in fact displayed. It was a relational ID that told the backend systems exactly which Tweet from which advertiser was being displayed. It was supposed to be storing these IDs. Did nobody think to test that the thing was, in fact, storing IDs? Especially for something that puts hundreds of thousands of dollars on the line? Even if you're actually passing that value off to some 3rd party system somewhere, you can verify that this slice of your problem (the React component that receives a prop) is doing its job properly. Even if that means stubbing it to log locally. Something?
  - doctor_eval 3y ago
    The problem is that in a large system like Twitter, the backend code that stored the ID is very distant from the front end code that generated the tag. I’m not defending this or anything, but you said that this should have been manually tested, and I’m just observing that manually testing a system as complex as Twitter, in any kind of comprehensive way, is not at all trivial.
    - mostlysimilar 3y ago
      I get you and that makes sense, and we're discussing things at a scale that I don't have experience with. I just wouldn't have been comfortable shipping this code without observing it functioning in some way. If your production environment is so complex that you can't properly test things locally then you should certainly have a staging environment that makes that kind of testing possible. I would never be satisfied doing zero manual testing of the code I ship.

doctor_eval 3y ago

But the advertising tracking system is not the thing they just built. That’s the problem. They included a tag that included information that was to be passed to that other system, to indicate that this tweet was billable. Presumably the tag was optional, the tag was just misspelled, so everything appeared to work just fine. It’s the downstream systems that cared about this tag and they were presumably not even running on the dev machine on which the offending code was written. The only thing that could have prevented this was some kind of schema that would have rejected an unknown tag at build time. Hence, typescript.

rmbyrro 3y ago
That's one of the main reasons why automated tests exist: to make sure a change in one area is not breaking anything else in the system. I'm not against strong typing. Just saying this is a bad argument in favor of it.
- doctor_eval 3y ago
  But the comment I was replying to said, > I'm not talking about automation or integration testing or any of that
mostlysimilar 3y ago
I see your point but the article says this: > This property was then used when logging visible Tweets that it was in fact displayed. It was a relational ID that told the backend systems exactly which Tweet from which advertiser was being displayed. It was supposed to be storing these IDs. Did nobody think to test that the thing was, in fact, storing IDs? Especially for something that puts hundreds of thousands of dollars on the line? Even if you're actually passing that value off to some 3rd party system somewhere, you can verify that this slice of your problem (the React component that receives a prop) is doing its job properly. Even if that means stubbing it to log locally. Something?
- doctor_eval 3y ago
  The problem is that in a large system like Twitter, the backend code that stored the ID is very distant from the front end code that generated the tag. I’m not defending this or anything, but you said that this should have been manually tested, and I’m just observing that manually testing a system as complex as Twitter, in any kind of comprehensive way, is not at all trivial.
  - mostlysimilar 3y ago
    I get you and that makes sense, and we're discussing things at a scale that I don't have experience with. I just wouldn't have been comfortable shipping this code without observing it functioning in some way. If your production environment is so complex that you can't properly test things locally then you should certainly have a staging environment that makes that kind of testing possible. I would never be satisfied doing zero manual testing of the code I ship.