Click here to monitor SSC

Tony Davis is an Editor with Red Gate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the Simple-talk.com and SQLServerCentral.com websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his Simple-Talk.com blog or his SQLServerCentral.com author page. As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management. In his spare time, he enjoys running, football, contemporary fiction and real ale.

The ALMs Race

Published 16 September 2011 11:43 am

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.

Cheers,
Tony.

13 Responses to “The ALMs Race”

  1. Alex_Kuznetsov says:

    Martin Fowler does not recommend neither TFS nor Rational ClearCase for Agile development:

    http://martinfowler.com/bliki/VersionControlTools.html

  2. Gavin says:

    Not sure that vendor lock-in is such a big deal; after all if you employ 50 ASP.NET developers you are pretty much locked in already. Obviously this doesn’t apply to Java/C++/other, but having made the decision to commit to .NET you may as well use the available tools. As for me, I’m a database developer, and the benefits of datadude, particularly when combined with team build, are sufficient to justify the downside of lock-in.

  3. rjemp says:

    I am not a TFS apologist, but your comment about working offline is not accurate.

    You can work offline perfectly well for most scenarios. What you can’t do is something like create a local branch, then check-in to that local branch and roll back changes to the local branch.

    You can work on existing projects, add/remove/modify files, add work items…. as much as you want offline.Then commit them to the server when you come back online. You can even branch offline.

    As I said, the only thing you can’t do is start running your own local repository with its own history and check-in / rollback to that local repository.

  4. IvanL says:

    I must say that if I read between the lines I sense allot of negativism towards TFS and I sincerely wonder why. As a .NET Developer I’ve been working day in day out with VS and TFS across multiple versions.

    “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.”
    This part for example is alien to me… 2-3 days / week our development team works remote from home… using TFS. VPN connections assure our access to the TFS server. And when there is no connectivity we simply work offline, merging in the changes when connectivity resumes.

    “bug tracking within TFS is not universally admired, for example”
    Some tools can greatly change this perception such as the TFS power tools and Telerik’s Work Item Manager, both which are free of charge. I most certainly recommend taking a look at them. I’m most curious as to which parts aren’t admired as I personally have never had any trouble or pain with the system and neither have our customers who for some projects have access themselves to our TFS Project Portals where they can add bugs and feature requests and follow up on how their projects are faring. This level of transparency has given customers a great deal of trust in our development teams.

    On the “Vendor lockdown” I share the same thought as Gavin, we are vendor lock in by our choice of developers and projects rather than anything else… If you have 50 java developers chances are you’re having a different set of tools but which is likely to be more or less the same as another java team. Stable choices are limited.

    “they should, surely, have open APIs”
    VS + SVN = AnkhSVN and I know that there’s other extensions out there for example CruiseControl.NET which plugs in to your TFS environment for continuous integration… It’s possible… just that the amount of people that make use of this are limited as most are ‘happy’ with the default capabilities or simply don’t care to expand their knowledge regarding the subject as the learning curve rises to be steep quickly.

  5. BuggyFunBunny says:

    A bit of history. The first (by most lights) IDE for the PC was Turbo Pascal, about 1983. The reason Borland did this was because DOS (and Windows, et seq) didn’t have the “tool box” mindset of unix, where each developer used the tools that were best. Source control was, of course, centralized. DOS simply didn’t support this, even for a develop working solo. Thus the character mode IDE was born. *nix folks still tend to the “tool box” mindset, although Eclipse and similar have changed some minds, while hardening others against the IDE idea (that is a pun).

    For the Fortune X00 coder cube drone, being told when to do everything, including when to visit the loo (I’ve not been subjected to that, but I do know some who have), having to use a particular “solution” is just more of the same.

    As to current state of java; if you’re in a Fortune X00 situation you probably use either IBM or Oracle IDEs. But you don’t have to. There’s still a lot of development in java which comes from all three OSs.

  6. Keith Rowley says:

    I certainly agree with you about the API issue. Particularly with the abilities of new web apps like “If This Then That” open standard API’s for all programs where this is practical are, I truly believe, the way of the future.

  7. Marc Joop says:

    Sorry in advance for not commenting on ALM, but is is lost in the TFS inaccuracies. I probably don’t need to elaborate, as IvanL has corrected enough of those points already.

    The Martin Fowler reference from Alex_Kuznetsov, aside from just being an appeal to authority, has to be analyzed in the context that Martin Fowler doesn’t like Microsoft.

    Further, given that the main difference between TFS and the more trendy Git/Hg tools is the ability to have local disconnected repositories, the whole Martin Fowler movement is inconsistent. On one hand he wants the power of local repositories and on the other hand he is advocating agile and continuous integration. I don’t understand how in an agile environment, where you are supposed to be delivering small incremental improvements, to a shared code base, with daily builds, why do you need local repositories. You should be checking in small pieces of ‘done’ work to the team’s repository, not creating a pile of secret local branches that are never shared with the team.

  8. Alex_Kuznetsov says:

    I guess we should go just a little bit easier on TFS – no tool can satisfy everybody and meet every possible requirement. TFS promises to, quoting directly from MSDN, to “apply proven practices to manage your application’s lifecycle” – and it does deliver what is promised, no argument here. It probably does not promise to provide the best tools, or to allow us to customize it easily; at least I did not find such claims.

    So we should not expect it to be easy to customize, or its every feature to be the best available. I might be missing something, but this is how I am interpreting the following MSDN article:
    http://msdn.microsoft.com/library/fda2bad5%28VS.100%29.aspx

    IMO, TFS does deliver what is described on that page, and we should not be blaming it for not doing something it is not supposed to do.

    Let me use an analogy: an ALM suite that provides a comprehensive set of solutions is like a Swiss Army knife – it does allow us to solve lots of problems. Whenever I go hiking, I take a Swiss Army knife with me, and it is a wonderful solution for hikers. Trust me.

    However, when I am at home, I am using lots of specialized tools. I can open cans with my Swiss Army knife, but I prefer a can opener – it makes me more productive. Similarly, a have a corkscrew to open wine bottles. This list can be continued with screwdrivers, carving knives etc. This does not mean that I am biased against Swiss Army knifes and/or the vendor that sells them. It simply means that I am choosing the best tool for the task at hand, and different tasks may require different tools.

    Similarly, Agile developers prefer to use specialized tools, the best tools for the task at hand. The reason is simple: it really boosts productivity.

    For example, being agile, we really need to have lots of branches, to create them and merge them back easily and frequently. Because we do that a lot, it is more profitable to have the best version control tool for agile environment, than to lose productivity with less than the best one.

    Naturally, not everyone agrees on “the best version control tool for agile environment”. However, I would suggest getting your hands dirty with git or Subversion for a few days before replying to my post – you might like them (git or Subversion).

    Open two hundred cans of sweet corn with a Swiss Army knife.

    Open another two hundred cans of sweet corn with a can opener.

    Feel the difference.

  9. Marc Joop says:

    I have used Git for my personal pet projects for a few years. In my professional work I have used subversion for 4 out the last 6 years, including the last 18 months, and the other 18 months I worked on two different contracts using TFS.

    I can accept there is a good argument that Git is better than TFS (for source control, not necessarily integration), but as soon as you threw Subversion into the equation you revealed a prejudice (anti-MSite perhaps).

    I like Subversion, it does a good job, but it simply doesn’t have any practical benefits over and above TFS, regardless of Mr Fowlers graph where the x and y axis are both opinions (recommendability and required skill, that really cracks me up).

    Subversion is better than TFS because it is more recommendable, there is a text book logical fallacy if I have ever seen one…..

  10. David Atkinson says:

    The version control component of TFS has a very healthy market share market share, and is pretty solid in comparison with the competition. The bug tracking may not be the strongest feature, but the IDE integration is second to none.

    Microsoft also allow integration points allowing third party ‘best of breed’ tools to integrate into TFS. However, the reverse is not true. Microsoft’s individual ALM tools only ever integrate with themselves via TFS, which seems to indicate that Microsoft isn’t even attempting to compete in the ‘best of breed’ category, with the exception of version control. I think it would be healthy if Microsoft re-evaluated this position. If their bug tracking project team were in direct competition with JIRA, it would have to improve to survive. Because Microsoft’s value proposition is to provide the most VS-integrated solution, which they are, there’s no incentive for them to improve it beyond that.

  11. Tony Davis says:

    Thanks for the many comments. The post was not intended as a dig at Microsoft or TFS and I apologize if it came across that way. We’re definitely not “against Microsoft”; Simple-talk spends most of its time covering Microsoft technologies and one of our authors provides a very positive review of TFS here: http://www.simple-talk.com/sql/reporting-services/hosted-team-foundation-server-2010-review/

    The point was not that TFS is bad but rather that a proprietary interface between components of an ALM can be problematic.

  12. dkalemis says:

    Tony Davis raises some important points and concerns here. But Derek Hammer has already blogged about them in considerable depth in his blog post “TFS is destroying your development capacity” at http://www.derekhammer.com/2011/09/11/tfs-is-destroying-your-development-capacity.html.

  13. greentian says:

    I sincerely doubt that there is “One ALM to Rule them All”. And why should anyone believe that there will be?

    For example: If you have an Access ADP project of any size the various SubVersion related add-ons just do not provide the needed reliability. But if you only have a small project of this type it will probably be fine. So TFS works better in the case of the very large ADP project. Perfectly? Of course not.

    If that is your case, does using TFS lock you in? To some extent, Yes. But if it is what makes the project viable, then that is what it takes. It does not seem worth the effort to do a fancy dance to use some favorite answer that adds complexity.

    If you have a open source project going on, why should you try to keep it in TFS? Just because you have it? An open source tool such as SubVersion is more reasonable and much more closely fits the developer base.

    Does everyone in a shop code using the exact same tools for all projects? With the exact same design and implementation approach? Really? Few developers write all of their code in one language, using one tool, for their whole life.

    Database developers often run across a range of databases, from Microsoft SQL Server to Oracle to Sybase to MySQL to NoSQL… That is how life goes.

    Choose your tools, not too few, not too many, and then carry on with the work. Even if everyone used the same tools, without a very firm discipline the approaches, designs, and so on can easily vary widely and cause more grouching about how things are done, than switching between a couple of tools.

    Or that is how it seems at this time of night.

Leave a Reply