I kind of like my software as I like my cars: Simple, and easy to troubleshoot.
The more predictable behavior, the better...so choose your tools and methodology wisely. The older I've become, the more I appreciate doing something that might be hard and challenging / lots of up-front costs during development, if it yields a robust system which is easier to fix, should something happen. So I will go for battle tested solutions, over the novel ones.
Yeah I like this idea, too. Testable, reliable -- and simple as possible - more important the more experience I have. I find myself leaning and advocating for the simpler of options, the one that gets to prototype, or feedback or PoC, sooner, knowing that more can be added later. Broad strokes, then fine strokes.
One silly but I guess not bad "test" I had for a technology or choices was: If I had to debug this for a critical problem at 3AM coming home from something else and am intoxicated, can I do it? If it doesn't pass that test (the "can I debug this at 3AM drunk" test), if it's too complex, I'm wary of it! Hahaha :)
The more predictable behavior, the better...so choose your tools and methodology wisely. The older I've become, the more I appreciate doing something that might be hard and challenging / lots of up-front costs during development, if it yields a robust system which is easier to fix, should something happen. So I will go for battle tested solutions, over the novel ones.