i was reading some self help book and then cascaded to read the technical stuff and then business stuff🙄😁
Let' say you developed a drug and wanted to experiment the efficacy of the drug. You have so called control and experimental groups. was good high schooler huh😁
If some patients drop out because the side effects are too severe, what would you include in your dataset for analysis? The ones who strictly followed the prescription or just the category you made earlier(Intention-to-Treat or ITT)?
it seemed to me it applies to software engineering related stuffs too.
Imagine you optimize a caching engine, check your dashboard, and ghost us like
Average Latency: 12ms 🚀
You're ready to celebrate. But you look closer and realize under high thread contention, 15% of requests hit a race condition and time out completely. The remaining 85% are just blindingly fast.
If you measure your system's performance only using the requests that succeeded, you are committing a classic Per-Protocol Error. You're bragging about a 12ms latency while ignoring the fact that you broke the app for nearly a fifth of your users.
The ITT principle says: If you intended to process it, you have to count it. When you factor those 15% timeouts back into the math (since a timeout practically means infinite latency), your brilliant new architecture is actually a downgrade.
@CompileTimeThoughts
Let' say you developed a drug and wanted to experiment the efficacy of the drug. You have so called control and experimental groups. was good high schooler huh😁
If some patients drop out because the side effects are too severe, what would you include in your dataset for analysis? The ones who strictly followed the prescription or just the category you made earlier(Intention-to-Treat or ITT)?
it seemed to me it applies to software engineering related stuffs too.
Imagine you optimize a caching engine, check your dashboard, and ghost us like
Average Latency: 12ms 🚀
You're ready to celebrate. But you look closer and realize under high thread contention, 15% of requests hit a race condition and time out completely. The remaining 85% are just blindingly fast.
If you measure your system's performance only using the requests that succeeded, you are committing a classic Per-Protocol Error. You're bragging about a 12ms latency while ignoring the fact that you broke the app for nearly a fifth of your users.
The ITT principle says: If you intended to process it, you have to count it. When you factor those 15% timeouts back into the math (since a timeout practically means infinite latency), your brilliant new architecture is actually a downgrade.
@CompileTimeThoughts