(no title)
SlavikCA | 1 year ago
I always suggest the "principle of lost packets".
Let things fail early to inform about your limitations. If your internet connection speed is 30Mbps and you send 100Mbps upstream - some packets will be dropped. The earlier packets get dropped - the better for the connection, because feedback will be faster. Ideally at your router.
Practically speaking, for the case in the article: We have 6 doctors working at our hospital. One doctor quits. Look, we're doing ok with 5! Let see, can we do with 4? Sure. Ok, now we're with 3 doctors and things are failing... So, 4 is probably optimal. Well, that 4 doctors working on the edge. Would this doctor "fail the hospital" earlier, - hospital will receive that signal, and doctor's count will be higher.
Few years ago I was promoted to be QA Manager, and learned very quickly, that a lot of people will make sure that I know, that if our QA team will not sign off on that release - we'll lose that deal, or make that client unhappy... At the beginning I tried to accommodate. But that was totally unsustainable. So, I quickly learned to give people realistic expectations: - no, will not complete QA by Friday, tell the client whatever you want, or give me 2 more people (and the only people they can give me were Developers). - no, will not have that release ready by 12th, you should have consulted with me before making promise, not it's on you to figure out, not my headache.
No comments yet.