Some counterpoints and personal experience: > 3. If you have a small team that hires slowly, it's relatively straightforward to bring new devs up to speed on "

Some counterpoints and personal experience: > 3. If you have a small team that hires slowly, it's relatively straightforward to bring new devs up to speed on "the way we do things." if you are hiring rapidly and/or have a large team, the more bespoke things you have, the harder it is to maintain them. I disagree that framework or no-framework is the distinguishing characteristic. I do think that the quality of the code base, documentation, and onboarding plays a role in how fast devs get onboarded. Anecdotally, the only framework-based projects I've signed on to ended up incurring more onboarding time because I had to learn the framework, how the framework does things, and then how the team does things in the framework. All of this "how" is a step before "why", of which, every step eventually needs to be repeated over the course of my tenure in order to be successful. > 4. Over time, everything degrades. In the long run, many framework-free applications either get walled off as "legacy" apps with new work done in separate services, or replaced outright. If it makes you money before that happens, you win. It is not necessary to try to design architecture that will last for centuries. I've personally never seen this in any language except Java. Spring might as well be Java at many companies. The bespoke applications stay around, in my experience, because: - They exactly match the business requirement and that requirement doesn't change much - People don't know how to work on them or the product has little funding, probably because of the above reason - The company has hired a team to maintain the product that have not moved I've also seen where companies try to replace something bespoke with something written in a framework where the budget expands multiple years in a row and the project never completes because it's impossible to make the framework do what the bespoke product did completely. > 5. My last and--to me the most significant--observation is this: You want to pay the majority of your attention to the code that has the greatest impact on your desired outcomes. To me, this reads as, "we should spend the majority of the time focusing on our core competencies". I've heard this time and time again in this industry and no matter what way I've heard it explained I've never liked it. Businesses that only stay in their core competency, or narrowly define their competency, often stagnate with time. There's a lot less opportunity for organic business growth with that mindset. They'll also have little expertise to solve problems as they scale, other than through purchasing, because they only have knowledge that serves their core competency. The businesses I've seen become most successful alongside strong technical success were businesses that encouraged employees to innovate and experiment in new ways on a rhythm, allowing that innovation to inspire and percolate when it finds a strong usecase.