This was my approach to a large rewrite I'm working on. First create the multiple layers of test suite to map out existing behavior at the unit, API, and integration level (something that should have been done incrementally over the 20 years this software has existed), then predicate the new code on the tests. It's been remarkably effective.
I'm not sure it's really from the lack of change, though. I've used Claude, Kimi, and other LLMs to write a ton of Perl that's jacked up with weird sugaring packages like Moose and Function::Parameters with reified types, and they seem to pick up the new idioms pretty effortlessly. It's a really unexpected fluency, frankly.
For us nerds in the Portland/PNW area, the Rice Museum out in Hillsboro—despite a name suggesting it has an exhaustive display of rice varieties—has a terrific collection of large and unique mineral specimens.
https://www.ricenorthwestmuseum.org
I wonder if there would be as much pushback here on this article if the conclusion to these 10k words of cited historical analysis had been to discourage the phrase's continued use because “we're besmirching our reputation as engineers using this idiom inaccurately” vs. “we're inadvertently maligning and hurting people by using this idiom inaccurately.”
In addition to the great lighting, the new design also has much improved acoustics. The sound dampening is impressive. I can have conversations without straining to pick up words through the din of echoes, and the ambience has a nice warm sense of quiet.
You might find Rag to Riches' (R2R) built-in use of Unstructured for doc parsing, hybrid search, knowledge graphs, and HyDE queries improves the quality of your retrievals. https://github.com/SciPhi-AI/R2R
Do you really need to comment to yourself or anyone else that you did a thing the less efficient way because it was simpler? I guess I"m not seeing the use. When later you've perturbed the criteria that caused that function's inefficiency to be immaterial to overall performance needs and it suddenly becomes material, profiling is going to reveal the low-hanging fruit faster than digging through the code for a “this could be faster a different way” comments.
If you have ever not gone somewhere because “there's too much traffic” or chosen to go to a store because it has easier parking than an equivalent alternative store, you've experienced the rudiments of induced demand.
Counterpoint: most innovation sucks. Sure, innovation is necessary for improvement and adaptation to changing circumstances. Sure, sometimes innovative change is stifled to the point that organizations crumble under the stasis. But the larger and more stable the organization, the higher the bar should be between “I have a great idea that will make things better!” and its implementation. Most ideas of change do not take into account the complex, multiplicitous, overlapping, crossed-purpose systems that conspire to bring an organization to life. They account for only locally perceived changes, not weird, unpredictable knock-on effects that can arise from introducing an optimization. Adopting every ostensible innovation that comes along is inviting only chaos. Change should be hard. Not impossible, but hard.
It's so bad I often wonder if I've done something to inadvertently screw up whatever vector database is used to weight the guesses on my particular phone. It's just hard to imagine having this bad of a user experience of a fundamental function be widespread.