When implementing some new functionality, certainly my own best practice is to never add just one project when I start a new piece of work.

Blue Skies and Green fields

Consider that nicest of scenario's the blue sky, green field development. I'm assuming that you have a full set of requirements that aren't going to change. What's the first thing that you do?

• Use the class Diagram to sketch some interactions ('Bottom up', 'Top down' or somewhere between)
• Write a set of comments or method calls that outline the functionality ('top down')
• Write a Test ('bottom up', 'Top down' or somewhere between)
• Create your UI ('Top down')

All of them are possible with varying degrees of 'rightness' but lets consider what do you want to deliver? One thing that still seems appropriate to me is the difference between functionality and framework and here's a great example. All of the above could be correct, either individually or in combination. So lets go one step further, lets do all of them.

Real world development

Consider an example. I'm going to write an FtpTask replacement, from my requirements I really want a suite of tools, that will reuse the same functionality.

• Unit tests will call the functionality and test it
• An MSBuild task will call the functionality
• A console app will allow the functionality to be called outside of MSBuild
• A Gui version will call the functionality to test the parameters given and generate an MSBuild configuration script (just like NCoverExplorer)

So my solution already has four projects just for the frameworks, and I will need at least one for the functionality.  Now I can do everything I might have wanted to.

• Unit tests have a project to be developed in.
• Class Diagrams can be devised for the functionality in the Functionality assembly and if required in the framework assemblies
• I can even start building my code calls/comments or creating my UI if I want to.

Production systems

Recently I've found this works so well I have started doing this for all of my work. I personally use Unit tests/Class Diagrams to develop the functionality, I provide a UI test harness which can even be deployed to production environments to assist with issues, and of course I deliver my functionality in the desired production framework be that WebService, Service, Web Application, Windows Forms or Console application.

Honest you're saving yourself work in the long run.