Early in March the MVPs are holding their annual summit on the Redmond campus. They want us to provide questions to be posed to the Microsoft managers who want to hear what the developer community thinks.
Please feel free to comment. I’ll pass on your comments to the folks on the hill.
- What progress has been made to better communicate between the various divisions at Microsoft? Case in point (one of many): The new Local Data Cache has two separate mechanisms to create and initialize the class. This means that the same properties are exposed differently by the two tools (one is a wizard, the other a designer). Another point: Why is there such a difference between the functionality exposed by the Visual Studio Server Explorer and the SQL Server Management Studio Object explorer? For years (decades) we’ve seen a chasm between the data teams and the Visual Studio/Languages teams as they struggle over features and functionality. As a result we’ve seen repeated cases of duplicated efforts and different interfaces/explorers/tools that expose most of the same stuff.
- Why was basic functionality removed from Visual Studio or not included when the technology evolved? For example, when Visual Studio 2005 shipped we lost the ability to drop a stored procedure on a form and generate a class that included a populated Parameters collection. This was not replaced in 2008. When Visual Studio 2005 shipped, there was no support at all for existing BI projects. This did not arrive until Visual Studio 2008 SP1. When the new ReportViewer control was released for VS2008 SP1 the ability to use the RDL generated by the BI tools was left off.
- What emphasis has been placed on addressing the long list of issues that I and others have raised over the years. We keep hearing about how resources are tight but schedules keep getting shorter as release cycles are shortened but there seems to be more than enough time to introduce new, complex features for the largest IT organizations.
- Why has the emphasis shifted from the small-to-medium sized shop supporting 1 to 25 developers to large IT shops that support hundreds of developers per project? Doesn’t Microsoft realize that the bulk of VB6 customers were in this area? Does Microsoft really think inventing yet another language or development paradigm will win back these disenfranchised customers?
- Why does Microsoft seem to think it needs to “productize” development tools and push their development teams so hard so that needed functionality is left behind? By shortening the release cycle Microsoft makes it nearly impossible for adequate documentation to ship with the product. For example, look at the help topics that ship with the newest technology—too many of the topics are clearly machine-generated placeholders that were never filled in. Independent book authors and publishers cannot afford to pick up the slack with this degree of churn. When you make your product obsolete in 18 months, you kill book and training sales and the incentive to document the missing pieces not to mention the developers who have to constantly retool.
Why isn't Karl Seguin an MVP (http://codebetter.com/blogs/karlseguin/archive/2009/02/03/why-aren-t-i-an-mvp.aspx) ?
Seriously though, I'll agree with every point except the last. 95% of all .NET book are meaningless cheerleading which promote horrible practice and focus on the API rather than whats truly important. If something's "killing" their business, I sincerely think we're all better for it. There needs to be _less_, not more, emphasis on the typical type of MSDN documentation (APIs) and more on industry accepted patterns and practices. This type of documentation should largely transcend product versions. If we're finding that documentation is lacking, its because its focusing on the wrong thing.
I completely agree that the Visual Studio language teams need to stop focusing (at least for one release) on new technologies that are applicable to only a handful of developers and focus on cleaning up the long-standing issues that will affect all developers.
While I agree the MSDN documentation has issues in placed; I agree with Karl that most books simply regurgitate information in, or that should be in, MSDN and provide poorly designed code in example form-sinking to the same level as the MSDN content. MSDN should focus on the syntax and the sematics while books should show people *how* to use a technology or API. If you feel books just take up MSDN slack; then the content of the book is likely doing the reader a disservice.