I am Sadagopan, a development lead in the Visual Studio for Devices team owning among other things the Native and Managed IDE story for devices. I was in the Visual J# team previously and you can say that development tools and programming paradigms including the Drag-n-Drop RAD VB methodology are something I am deeply interested in. I will be talking about most of these areas in the coming few months/years.
When I started off programming (a little over 12 years ago in school for my under-graduation), my IDE was comprised off 3 disparate pieces, Emacs as an editor, a command line compiler gcc and finally a set of printf statements for debugging my application (okay, those were pretty small applications that did nothing really useful, but...). As I graduated, I learnt to use gdb integrated into emacs and that was better though the command line interface into the debugger was not very user-friendly. But, there was no nice way of writing programs easily and debugging was hell - you were lucky if it worked right the first time else you can forget the nice long weekend or sneak off for a movie before the assignments were due.
Grad school was a little different - you had to get a little savvy if you wanted to debug your implementation of XINU on DEC stations. I learnt to use the debugger more effectively and other debugging techniques like asserting in the programs and good logging. It was then my research work took me into the world of Java programming and I can say it was pretty boring and too easy. I still used the good old emacs editor with syntax coloring which was pretty neat.But as far as I was concerned that was just "syntactic sugar" to my editor.
I joined MS in 1999 as a developer in the Windows Base OS group. And the first tool that I was introduced to was kdb - the mother of all debuggers. It teaches you Zen like patience and in addition also lets you peek into the bowels of the NT kernel - not very appetizing before dinner, I assure you (Windbg has kernel mode extensions and is somewhat more user-friendly though). This was the time I also got introduced to Visual Studio to write C++ MFC based applications. In two days, I was hooked (and finished with the skeleton of my application as well). After trying out various macho(istic) tools, I was finally at home. The syntax coloring and the intellisense support with F1 help was pure manna from heaven. It was then that I realized what "IDE" stood for!!!
Well, to cut a long story short, I moved to the J# team in the middle of 2000 and was with them till as recently as April 2005. I worked on the libraries that we shipped with J#, then with the compiler, then with the IDE team essentially covering all angles of development with J#. It was here that I learnt the value of engineering processes in development and the importance that tools played in them. In addition to cordbg and the mixed mode debugging of Visual Studio, there were a suite of tools that improved the product quality. The complexity (and in some ways the flexibility) of C++ gave way to a more structured approach to programming in C#, VB .NET and J#. The C++ compiler accomodated static analysis through PREFAST and FxCop did the same for managed code.
One might wonder if all I did at Microsoft and earlier was debugging (with all the stories about the number of bugs in MS products floating around, I really dont want to add to the fire :-), but that was one tool that really affected my productivity. When I moved into the IDE team for J#, I really started to see the entire IDE space and the amount of effect that it has on the entire software lifecycle of an application.
Microsoft development process in the developer division group are medium-large scale (compared to the mammoth Windows platform environment for example, it is rather puny :-). There was a development process followed here where code was organized into a structure and individual products in Visual Studio were kept seperate by the simple mode of using different directories. Everything was command-line driven to help with automation including our test harnesses which guaranteed minimum quality of the daily build. That worked well since all processes were end-end driven from the command line. If I look at Visual Studio Team System today, it brings some of the power that we have with our internal development environment in a more usable intuitive way for all the roles and phases in the Software development cycle.
Software engineering has become much more complex than it was a few years ago. Development has grown beyond the space of just writing good code for a product. The issues faced by development teams are extremely diverse depending on the role of the individual in the team and the phase of the product in question. Marketing needs to gather customer requirements and put them in a form from which technical feature specifications can be written. Once the feature specifications are written, architects need to design the architecture of the system and then individual feature teams carry out the implementation and sign off on the feature followed by integration testing before deploying into the customer hands. The product is then maintained and customer requests are integrated back into the product. As you can see, I am simplifying the process involved and looking at only the high-lights of the entire software life-cycle. But, even here one can easily begin to appreciate the complexities involved. It requires an extremely integrated framework to pull all these pieces together so that there can be the required amount of interaction and feedback between the various phases but at the same time respects the differences between them.
Visual Studio in my opinion tries (remember that the keyword is 'tries' - we have made significant inroads but there is tons left to do in the future) to address these issues in a completely integrated fashion. There is a plethora of tools in the box (not in the Toolbox window though :-) that help development teams to stay connected and improve their productivity depending on the role that they are in. If you are a software architect, there are tools like the Class Designer that help you look at the high level of the system. As a developer, there is the familiar Visual Studio environment with a larger assorted bag of tricks like the static analysis tools and the enhanced editor features like Smart Tags and better Intellisense (just does not have the sense to shut up when I want it to though - telepathy would help :-). The unit testing framework ensures that features that are checked in meet the required quality bar. Integrated also is the source control system Hatteras and the Currituck Issues Database for manegerial types like myself to keep track of the status of the project and do precious little else :-) Team Build deserves a special mention for integrating all these together to provide an easy build system for product teams to automate their build process. Product packaging in the form of Click once and the deployment project system help in building that package around your product easily.
Well, that sounded like an advertisement for Visual Studio Team Suite, didn't it? But, as I stated earlier, I am really excited to be part of this space and I can go on talking about this forever. After all, what could be better than to be part of a group whose customers include myself. What VSTS envisages is stupendous and mind-blowing and we have not even scratched the surface with what is in VS 2005.
The product itself is huge comprising of a number of different teams working towards a common integrated development environment. In some sense that itself is an engineering marvel - pulling together teams with different customers, different goals and priorities for their individual customers into one release. I know and accept that things can be better in terms of bringing this innovation to the market faster and in a more sustained way, but a larger ship does take a little longer to turn and we will turn. There are lots of people like me who recognize this problem and are actively working towards a solution and when we do, I think we will be able to even incorporate some of the lessons that we learnt back into our tools creating a stronger eco-system around our platforms. While, it will not be possible for me to cover all the areas, I am going to pick one area at a time that I personally think is changing the way we think about development and talk about how VS addresses this and what can be done further in the future.
