Rob Pike's Rules of Programming (1989)
> Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.<p>I wish people would follow this rule and just let stuff work.  I recently encountered the most extreme version of this I've ever seen in my career:  a design review where a guy proposed a Redis caching layer <i>and</i> a complex custom lookup scheme for a <1GB, moderate read volume, super low write volume MySQL database.  And of course he wants to put the bulk of the data in JSON fields and manage any schema evolution in our application code.<p>Can't we just let stuff work?  I'm no fan of MySQL, but can't we admit that a ubiquitous and battle-tested piece of technology, applied to a canonical use case, on tiny data under near-ideal circumstances, is probably going to work just fine?  At least give it a chance before you spend days designing and documenting a bunch of fancy tricks to save MySQL from being crushed under a few megabytes of data.