- Tags:: [[Zettel]] [[Min-Maxing]] #[[Min-Max This]] [[Happiness]] [[Productivity]] [[Minimalism]] #[[Strength Finder Theme: Communication]] [[Software Testing]] [[Software Development]] [[Stubs]] #[[Stubbing for Load Testing]] - Source: [[sources/Book/How to Take Smart Notes]] - Date Created: [[2020-09-02]] - Related Zettel:: - [[Overcommunicate to your future self.]] - Overcommunication doesn't always meaning saying MORE; it means __communicating__ more, or saying the thing you mean and only the thing you mean. - [[Standardizing a process makes it repeatable and efficient.]] - [[Principle of Atomicity]] - [[Clarifying a project as a series of Next Actions makes it less daunting.]] - "Most products and services focus on giving us __more__: more money, more time, more success, more knowledge. The irony is that what makes us happy is __less__." - We should spend less on things that lead to the acquisition of more things and spend more on services that allow us to acquire less: less clutter, less stress, less pressure. - Truly valuable skills involve turning chaos into fewer, meaningful concepts. This distillation naturally requires the removal of unnecessary or irrelevant information. - It's important, however, to prune __with intention__. By keeping our objectives in mind, we can keep our work in line with our intentions. - While end-to-end load testing is valuable, sometimes it isn't feasible, especially for larger or more complex applications. Sometimes it is simply financially reckless to recreate every integrated system to test just one. - Other times, it may simply be unnecessary to rerun an end-to-end test when only one part of the chain has changed. - This is where stubs come in. [[Stubs]] - Stubs allow us to abstract out other components we don't want to test so that we can concentrate on the one that we __do__. The point of a stub is to remove the variables and noise introduced by other parts of the application so that we can focus on testing how one component responds. - The rigor of the scientific method teaches us how to get results by systematically excluding variables we are not interested in. Similarly, load testing a component in isolation can yield useful results because it allows us to focus on fixing performance bottlenecks internal to the component before jumping to load testing the whole chain of components, which may lead to seemingly conflicting information. - When analyzing load testing results, having more data is a good thing-- to a point. It's always good to __have__ data to draw on, but good analysis requires the isolation of two or three variables to determine how they affect each other. Looking at every single metrics from every single test is rarely useful. - What we can focus on, when analyzing results, is developing the knowledge and experience required to decide what to remove. In the absence of both, though, all is not lost; we can still systematically determine which metrics are correlated by the process of elimination and good old mathematical theory. #[[Load testing is a data science]] - "`Engineer: “I can write that code.” Senior Engineer: “Should we write that code?” Staff Engineer: “We should delete that code.” Principal Engineer: “Delete all the code.” `"