How did we get to the point where Visual Studio, and Team Foundation Server, so strongly influences our way of developing applications?
Visual Studio’s history is convoluted, and it is still expanding its remit. Microsoft originally bought in a prototype visual form generator. It was combined with the dialect of Basic originally developed for the Omega project (later Access) to create Visual Basic. Although the Xerox Star workstations were the pioneers of this sort of visual interface, Windows users had never seen an IDE like this; it was popular, and duly proliferated, with Microsoft releasing Visual C++, Visual Interdev, Visual Foxpro and so on. Eventually, Microsoft undertook Project Boston, which combined many of these tools into one product, and the result was Visual Studio 97.
For many developers Visual Studio is a still just a convenient, visual tool with which to build and compile their application code. However, the first hesitant steps in expanding this role came with the acquisition of Visual SourceSafe, to provide a rudimentary source control system. Since then Microsoft has been working hard to reposition VS as an Application Lifecycle Management (ALM) tool; i.e. one that not only helps you create code, but also provides a means to support all the operational processes that are necessary to guide an application from initial development (agile, of course) through testing, to release and maintenance.
Visual Studio 2005 Team System (rebranded in VS 2010 as Visual Studio ALM) and Team Foundation Server provides a central, source-controlled data store accessed by the client (VS) via a set of web services, and providing features to support project tracking, build management, deployment, reporting and so on.
It’s a strong industry trend amongst the larger players. IBM offers its “Rational” set of integrated ALM tools and Hewlett-Packard has its own ALM offering. The advantage is an integrated, consistent approach to all aspects of DevOps, allowing the team to focus on business requirements, writing good code, and delivering, regular, incremental improvements to the users. The downside is, of course, vendor lock-in. A disadvantage of being cocooned with within a single-vendor ALM solution is that you could end up having to use products like Visual SourceSafe.
By adopting single-vendor ALM, you embrace the specific development model of your ALM platform and adapt established processes accordingly. Remote team-working, for example, isn’t easy within VS without Hosted TFS, so you tend not to do it. There is no notion of off-line working; if the network goes down, you stop working, which can be a considerable restraint.
You come to rely on that platform’s particular tools, and styles of working, even if it doesn’t really match your particular requirements. You may, for example, need a distributed rather than centralized source control system that allow for off-line working. A significant weakness in any one of the tools (bug tracking within TFS is not universally admired, for example) can frustrate the team and slow them down considerably. ALM components tend to be incompatible with any other but their own.
ALMs have the allure of any shrink-wrapped solution, but even if they offer all the tools you need to in order to support development processes, they should, surely, have open APIs and more pluggable architecture so as to allow development teams to swap specific tools in and out in order to fit ALMs to their own requirements, rather than the reverse? This is the area into which the likes of Collabnet and Atlassian seem to be moving.
I’d be interested to hear your thoughts.