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.