At the company I work for I want to improve the way we write software: designing our applications more SOLID. We've been in a new project for a few weeks and I've tried to apply some good practices in its design. For example, loose coupling by programming against interface instead of a concrete class, dependency injection / inversion of control, seperation of concerns etc. This is all meant as a springboard to test driven development in the (far) future.

In the application we're developing we need to calculate a score depending on a filled in survey by a user (a survey has categories which themselves have questions / answers). I've splitted the calculations in multiple classes and subsequent interfaces (calculating score of a question, category, survey, etc).

Also, in the front-end (ASP.NET Web Forms), I've splitted many parts of pages into seperate user controls. For example: a 'widget' which shows the culumative scores in the application or a widget for showing all files related to the application. These are all seperate user controls.

We're now a few weeks in the project and I find that some of my co-workers (especially ones older of age) are complaining about:

• Not being able to find a implementation of a interface directly but needing to 'search' for the implementation
• Needing more time to find the implementation of a particular markup on the front-page

They also don't see the point of splitting up seperate functionality into user controls because sometimes (usually) the user control is only used on one page. I, on the opposite, find it to work better since it keeps the code-behind of a page tight and lean.

My question is: Do I apply good practices the wrong way or does it simply take time to get used to it?

Note: Until very recently we developed software with tight coupling (e.g: static classes, never use interfaces, only use user control when necessary).