Microsoft never met any problem they couldn’t make more complicated. You can see this in nearly everything they do, from relatively simple things like the Zune — way, way, way more fiddly than the iPod — to their mess of a mobile platform (really? a “Start” menu on my phone? Are you high?) to how they manage server settings for tools like IIS and SQL Server to, well, even Word and Excel these days. Trapped my increasing commoditization, they keep shoveling more and more features into tools into which almost no one dives deep — my bet is that 95% of all Word users have no idea what 95% of the features do. And yet they add and add and add, and Word gets slower and slower and slower.
Complication is sin in computing. Simple tools are better. This is a bit of a religious position, but my 20+ years in computing has left me with the strong opinion that a whole bunch of flexible, small, generalized tools is a way better solution that an proliferating patchwork of giant, inflexible programs dedicated to single tasks.
My current proof of this is Team Foundation Server, MSFT’s current offering in the source-control-and-work/bug-tracking world. It is, of course, the path of least resistance for the MSFT developing hordes (while the rest of the dev world uses tools like Subversion). I’m not writing code on this project, so I can’t speak to that side of the tool, but as a product manager I do know something about the bug-and-issue-tracking side of the thing. And it’s a friggin’ joke. Everything takes ninety more steps than it ought to. The only way to interact with it, really, is to install and use VISUAL STUDIO — there is a web client, but it sucks balls even from IE8. If you’ve used more lightweight, flexible tools like Bugzilla, working with backlog of items in TFS feels like assembling a ship in a bottle with a broken pair of tweezers.
Of course, TFS does come with a rich set of templating features, and is skinnable and has workflow features and is all kinds of customizable. It’ll talk to Excel for bulk entry, even!
And yet, here’s the rub: none of that shit really matters for 99% of the people who need an issue tracker. It’s a pretty simple use case, which is why so many of the popular tools are simple web apps with little in the way of system requirements: Management uses the list to figure out what needs doing; they set priorities, and assign items to developers. Developers use the list of things assigned to them to know what to work on, and in what order. Dialog ensues on each work item as required. Everything should be simple and straightforward. Nothing gets lost in the shuffle, because the universe of items is fairly simple and easy to see.
Not in the land of TFS, though. You’ve got a boatload of work item types to sort out (bug? enhancement? product backlog item? sprint backlog item? task? there’s MORE!), and there’s no way to change the type post-creation, which is an EXCELLENT way to ensure some double-entry and/or the loss of an item because it’s in the wrong type. It’s thick-client dependent, but even that interface looks like something from the Land that UX Forget (constant scrolling, e.g.). It just took me 10 minutes to find the “jump to item #” feature, for crying out loud.
Who comes UP with this shit? Are they fired yet? Christ.
Welcome to my nightmare. We rolled out TFS last month. I was not given a choice..even the “highly paid consultant” (and ME..who actually WORKS for them) flat out stated in meeting after meeting that “the defect management tool is not ready for primetime..and won’t be for some time.” No matter, install Visual Studio (for defects!) and get on with it..total ridiculousness. It’s the path of least resistance to corporate tools who don’t know anything about software development..you hit the nail on the head. Good rant. GAH!
It’s a great tool if your actual goal is to sell seats of Visual Studio, I guess.
Therein lies the real problem with MSFT in lots of spaces: they don’t really care about solving the problem. They care more about how to make all their tools tie into each other such that you need everything. This is NOT a customer-friendly position, and only their market share makes it possible.
Hmm… I would be interested to hear more how it is in a development (code) perspective… evaluating it vs Subversion (even with an expensive client for svn, TFS is at least 3x the price.
I actually met someone who worked on the platform at a party a while ago, though only on the VCS part of it.
I realize it won’t make you feel better, but their own development process sounded enormously ham-strung by their own tool—seriously fucked-up process-wise.
I mean, I was extolling the virtues of DVCSs, and the way that Ironic developers are disciplined to develop on feature branches that, once they are ready, are only then merged to the product mainline. mainline stays more-or-less releasable (I mean, we do test, and bugs happen, but we don’t commit code to it unless it is at least nominally finished).
This guy told me that in their group, everyone checks their work into a single line of development for a development period, and then they have multi-month periods where they desperately try to stabilize things. Branching apparently sucks, and merging apparently sucks more, so it’s really not feasible for someone to work on a feature in relative isolation (but with VC) and then merge from mainline when they’re done with a feature. So mainline is perpetually in a half-finished state, and dependencies among features can’t be managed in an orderly way, etc.
Truly, they are probably even worse off than you.
I think Mr Dorman has some thoughts on point for you, actually. See above.
Hmm… I’m going to have to gather more data to convince people…
BTW, branch/merge in VSS 6 keeping track of which files have been changed/added manually is… lovely.