The worse thing is that he's saying "you shouldn't spend extra time to do the right thing", and then tries to justify that by giving examples of people doing the wrong thing. Nobody is calling spending weeks writing a caching layer for a 20-row database "elegant" or "best practice". That's a complete straw man.
I was involved in a software development project last year, in which the entire remote development team of 20 people got fired, because the software architect implemented a bunch of best practices, design patterns and state-of-the-art frameworks, without any thought as to how this would impact development time. The problem was that he was the only one who was familiar with most of this stuff, so there was a very steep learning curve for the rest of the team, who one by one either dropped out or became totally unproductive. After 18 months in which he burnt his way through the budget, with very little to show the client by way of results, the project was drastically scaled back. So this is not just about straw men. People like this really do exist.
Things like best practices become more important the larger the team. Are you suggesting the project would have been more successful if they had been less concerned about code organization and unit testing (or whatever you mean by "best practices")?
The problem was not the use of best practices per se, but the uncritical use of these practices. For example, it's good to use design patterns, but not every pattern is appropriate to every situation. We got to a point where it might take a full day to make a change to a table, and then make the corresponding changes to all the various repositories and entities. Similarly, it's good to use the latest technologies, but using beta versions of unpublished frameworks was a bit over the top, both because documentation was scarce and because they were still buggy.
"Nobody is calling spending weeks writing a caching layer for a 20-row database "elegant" or "best practice"
I don't disagree with your main points, but you might be surprised to hear some things that people will say and unnecessary optimizations they'll attempt...
Sort of. That just means they endorse an Agile approach - ship bare minimum features early, and continuously improve. Not ship bare minimum features early, and who cares about how its designed. The whole over-engineering argument is a straw man, because over-engineering is just as bad as under-engineering. Neither one is desirable in professionally written software.
