Staying the Course
I'm going to stray from LINQ to SQL to talk a little bit about software development in nature. In software development, developers are trying to achieve a goal of the customer you are working with. During requirements gathering, you find out all the particular details and aspects about the goal. When developing the architecture, you wonder what is the best way to get to the goal without making it too complicated or time-consuming, while making sure that the appropriate functionality is present. Hopefully, security, scalability, and maintainability are factors in heading in the direction of that goal. It is during this phase that you make certain choices about how the software should work, feel, and look, all for the purpose of achieving the goal that the customer needs and that your team needs (in the aspects of security, performance, scalability, maintainability, time consumption, etc.).
Software development is often about staying the course because as us developers think about the problem, we tend to think we have a better answer for the a small piece of the architecture at hand, or because it's the easier option. Easier is never a good solution because it often strays from maintainability. For instance, it's easier to hard-code values in an application, but for maintainability it's good to put constant data in a central place. It may be easier to embed SQL code in the UI for a challenging query, but it's better, more maintainable, more performant, to put it in a proc. It may be better to code your piece of the application a different way, but from the perspective of maintanability, it's better if the code is more uniform than not.
In application development, you have to stay the course sometimes and stick to the game plan. It's often for the good of the application.