Convention most of the time doesn't reduce boilerplate at all while it increases exponentially the headaches for anyone reading the code. A typical example is using the awful Prism way to display a view in a WPF application. For some reason completely alien to me the people at Microsoft practices, or whatever it was called at the time, explicitly suggested to use the IOC container directly (or with a kind of service locator) to create a view that automatically will try to load a view model with the same name if it existed, without throwing any error if it wasn't found. This is the worst possible suggestion ever. It is much easier and much more readable to just get your view model as a parameter in your main viewmodel, the IoC container will create it for you, you assign it to a public property and the view defined in a template is automatically shown in a content presenter. This is extremely easy, much easier to do than to explain, there is no whatsoever connection to the container, if the viewmodel is not found you receive a runtime error, the view model has no relation at all with the view, it can be called whatever you like and the view has an explicit connection with the viewmodel. So in this case the removal of convention based loading not only makes everything explicit, but also removes all the boilerplate needed to get a view from the container. I don't particularly like ROR exactly for the same reason for which I don't like this convention driven way just explained. And as you can see removing conventions and using different techniques can actually reduce the boilerplate if done properly.