No, it’s not. Changing requirements by adding features is by far the biggest cause of badly designed and buggy software. I’ve worked on multiple teams where everyone was fully committed and highly skilled, and it didn’t magically fix the problems of software. It wasn’t any better than working on teams of people who were less interested. Our inability to stop adding features is what kills us, and this inability is actually stronger with people who think they’ve ‘mastered’ the art of programming than with people who can finish a one-off task.

> they will probably not be a general purpose solution of the problem at hand

Ironically, perhaps, in my decades of professional programming, the number one biggest waste of money I’ve seen is people over-engineering something under the banner of making something “general purpose” that didn’t need to be. I’ve watched a couple of different teams of very smart people waste literally tens of millions of dollars by deciding to rewrite something that didn’t need rewriting, and dramatically overestimate their ability to finish it in a reasonable amount of time and avoid the same mistakes they made the first time.

> If you want to write dependable, high-quality, maintainable, reusable software you better know more than the bare minimum.

This sounds good in theory, but is specious. The real way to get high quality software is to define what that means and stick to it ruthlessly. You don’t need to know a lot about programming. You need a management that is okay lengthening schedules to make room for testing. You need a CEO who is okay with saying no to customer demands for features that the competition has. You need programmers who know when to stop programming and when to avoid rationalizing their ‘general purpose’ solution that solves problems that don’t actually exist.

Good luck in your search for high quality software, it’s very very difficult to find a team who can commit to it, and there are good reasons why: it’s extremely expensive.