From time to time this concept of "boring development" etc comes up. And to a point I get it: we've all been burned by people switching around tech to the lates

From time to time this concept of "boring development" etc comes up. And to a point I get it: we've all been burned by people switching around tech to the latest thing which ends up being buggy, poorly supported, and the benefits are nebulous at best ("oh, you rewrote this from a python framework to a ruby framework? I ... why did you do that? Seems like a lot of work for no real benefit...") But I think this sometimes misses some of the real upgrades that exist out there: - Strong typing really gives a benefit when you're refactoring, and other benefits in expressiveness when you can express what you want the solution to look like before you write the solution. - Going from "pile of interleaved CRUD / if statements" to designing thoughtful abstractions for your domain can simultaneously reduce code complexity and reduce the number of bugs you encounter. I think we sometimes overfit on "well, you say you're doing this for code quality reasons, but really you're laundering new-and-shiny distractions with code quality as a justification. In the end nothing will be different and we'll have wasted a lot of time". But in reality, these things do accrete over time, and some teams are dramatically more effective than others due to judiciously picking "exciting" things to work on. I think boring / exciting is a surface characteristic that doesn't correlate well with the actual metric you want, which is effectiveness and velocity gained. It's like arguing all day about whether your car should be red if you want it to go fast, it's just completely ignoring the facts on the ground about how things work.