4 ms·
WRT American pre-calculation and its relationship to software... One of the great personal epiphanies of my professional career was the discovery of data pre-c
by eldude 11y ago
WRT American pre-calculation and its relationship to software...
One of the great personal epiphanies of my professional career was the discovery of data pre-computation FLOABW. More specifically, what I'm talking about is data denormalization.
I had always been aware of caching techniques, but beyond that, data normalization was so ingrained into my mindset, that storing any piece of data that could otherwise be derived from another seemed like heresy, something only an amateur or fool would do.
What really opened my eyes, was when I was forced to build a social network atop MongoDB (ouch), and I had to resolve the incompatibility of relational data, but with atomic write, with no join or transactional support. What I discovered, was that if care was taken to create a canonical representation of the data, a multitude of query-able denormalized derived tables could be utilized, and could in fact offer dramatically superior performance compared to its RDBMS equivalent. What was especially shocking, was how obvious this was in retrospect and how blinded I was by the assumption that perfect data consistency was a requirement for all software.
I now view most tasks with the consideration, "What would this look like if we ignored efficiency in favor of raw performance and might that be worth it?"
- toast0 11y ago> I now view most tasks with the consideration, "What would this look like if we ignored efficiency in favor of raw performance and might that be worth it?" Raw performance is efficiency. You must consider space efficiency, CPU efficiency, network efficiency, time efficiency, developer efficiency, etc
- eldude 11y ago> Raw performance is efficiency. Efficiency is analogous to velocity, with gains analogous to distance. Highly efficient developers must still travel non-trivial distances to achieve performance gains, and therein lies the core of my epiphany, that performance is not efficiency, and highly efficient developers must spend non-trivial amounts of time to achieve performance gains that may in fact undermine development velocity, CPU efficiency per task, architectural efficiency (DRY), time efficiency (latency), etc...
- SixSigma 11y agoIt is better to be effective than efficient. By analogy: it is easier to make a fast car safer than a safe car faster.