Like many others whod long awaited Microsofts Visual Studio 2005, I felt more than a little let down when that development suite shipped without the full-spectrum collaboration tools that wed been told to expect among its most distinctive improvements. Microsoft now assures us that the Team Foundation Server (TFS) is forthcoming: Sources tell eWEEKs Darryl Taft to expect it in the first quarter of this year.
I get a queasy feeling, though, from a combination of comments by Visual Studio Team System Lead Program Manager Jeff Beehler, who told us all on his blog last week that (i) “weve been fixing tons of bugs” and (ii) “were only fixing the most critical of issues to help prevent regressions.”
Does that give anyone else a sense of “uh-oh”? Theres plenty of room for debate about the precise behavior of bug discovery rates as the number of remaining defects in code shrinks down, but I dont know of any model that estimates a sharp and sudden cutoff between “tons of bugs” and “good to go.”
Even assuming that the quality of the code will meet our hopes—and even, perhaps, exceed our expectations—I was struck by another assumption implied in comments about the imminent Team Foundation Server release. Darryls story mentions a blog post by Microsoft developer division VP “Soma” Somasegar, citing the degree to which the team thats building the companys life cycle tools is using those tools itself—”eating its own dog food,” as the common saying goes.
Well, that sounds like the best possible evidence that those tools will meet the needs of real-world developers, but is that assumption based on more than superficial analogy? Consider another, similar situation: Would it make you feel good to be told that the next generation of Ferraris will be delivered to the showrooms on trailers towed by Ferraris? Or conversely, that the power and handling of actual heavy-duty auto transports will be faithfully reproduced in the sports cars that those trucks carry? You wouldnt find those to be encouraging promises, because they equate the strengths that are relevant to one task with the needs of a quite different task.
Are the tools that optimally support a developer team like Microsofts, working on the kinds of projects and in the kinds of time frame that characterize their workload, necessarily the optimal tools for your team and its situation?
Personally, I look forward to the availability of Microsoft TFS, because the company is in fact one of the worlds most extraordinary software factories. The companys ability to envision new capability, and to realize that capability in products produced by widely dispersed teams, is unquestionably remarkable. Whatever magic beans may fall off their plates and wind up on ours are bound to do us more good than harm.
I wonder, though, if Visual Studio Team System will be a well-tailored fit for organizations that are only like Microsoft in the sense that they also produce software. The manner in which Microsoft designs and delivers product, and the kind of developer that the company is trying to enable and empower, may not look all that much like the manner in which an enterprise team has to work with business process owners, deliver incremental capabilities into heterogeneous IT environments, and respond under pressure to immediate and unpredictable demands of its own in-house clients and their supply-chain partners.
Its essential to look at developer tools in the context of the process that you actually have, which may or may not bear close resemblance to the process envisioned by the toolmakers. Ferrari ads may make you dream of a morning commute through the streets of Monte Carlo, but lets get real: Youre going to be driving in a completely different kind of traffic on a completely different kind of road.
Are there commonalities between what makes for a good ride in both situations? Yes. But buy whats right for the driving that you have to do in real life, not in your dreams.
Tell me what road signs your developers are seeing at [email protected].
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.