If you were following the previous post on File | New | ‘Blank Problem’ you will see we are a fair way from a development environment that provides us a starting point for defining the requirements for a solution, let alone a single environment for defining the problem. Until the day we can open Visual Studio, and create a ‘New Blank Problem’ file, where we can use a bunch of integrated tools to capture our problem and requirements as we think about them, the best thing we can do today is start to automate the solution implementation.
Of course initially, the key to getting started along the automation path is to either know about it or discover it, and hopefully avoid that phenomenon that most developers are familiar with – ‘The Visual Studio Stare’.
You suffer the ‘Visual Studio Stare’ when you (the solution architect/developer) know you have something to build, you know the (only) tool you will ultimately build it with, but you just don’t know how and where to get started with it….
…you suffer the familiar sinking feeling of the ‘Visual Studio Stare’.
“I just know that I need to do something, just don’t know how to start”
This phenomenon just illustrates the lack of tools we have today to conveniently and sufficiently express and capture a problem description. Subsequently, this forces us down the path of the ‘Solution-First-Approach’.
Getting started today in Visual Studio typically begins at the ‘Start Page’, and more often than not begins by opening the familiar ‘New Project’ dialog box where the beginnings of the solution begin to be defined.