SharePoint 2010- Content Types, Lists and UI for the List

In my recent project on SharePoint 2010, I came across with various options to create list, content type and UI for the list. Few of them that I played with were:
VS Code Approach:
SharePoint Guidance Approach
1. Create your content type 
2. Create your List Instances
3. Create the feature to assign Content Type to List Instances
4. Put the required code like removing other or default content type from list in feature activation and deleting the list in feature deactivation.
5. Create the Entity classes using SPMetal
6. Create your UI in the Visual web parts.


The approach is good but it all depend on your requirement. If your requirement is such that you want business to give the flexibility to be able to add new field, or to modify the view, then this approach is not the correct one for you. In most of the cases, since SharePoint is a system for business, you would like those features to be available for business.


Another issue with this approach is that it takes TOO much time to do a small thing. 


However it would be a perfect solution for a project where the requirements are pretty much stable and business should NOT be able to change things.


Then there is a middle approach, though with the coding approach only, to create list definition with custom list form in the code and deploying them. List definition approach can also utilize site content types and list content types or site columns and list columns. And you may put a custom list form within the project rather then creating a web part or visual web part. 


And then there is No Code approach where you use SPD. You can create your site content type. Though using site content type is probably not a good idea is the requirements keep changing or to be more specific, you see business coming up with new fields or change in field type frequently. So you can create your list columns and either customize the list form or use InfoPath custom forms. If you customize the list forms, you can get the benefits of all JQuery power that you used in MOSS and can do most of the things in client side and have more control on how things will be rendered. However InfoPath form is better if you don't want to go in SPD each time you have a little change or you have a tech-savvy business user who needs to power to be able to change things in UI. However most of the things can be done in both places like validation or RegEx validation and client side rules.