Integration is a tricky thing. When it works flawlessly, it is a huge productivity boon. But when you trust it and it lets you down, it is a huge time sink. Some examples: I used to work with someone who had a genuine fetish for tool integration. He wasted more time trying to get tools to work together than he did performing useful work. At the time, we were using JBuilder and Visual Source Safe (for my opinions on this piece of technology, check out VSS: Unsafe at Any Speed). The integration between these two tools was spotty at best. I never even tried – it was easy enough to keep the VSS explorer open alongside JBuilder and just bounce between them. But not Mr. Integration. He tried a variety of supposed integration plug-ins, each with serious shortcomings. Finally, exasperated, I told him that I had the perfect integration strategy. “I’ve fixed your JBuilder/VSS integration. First, open both of them. Second, I’ve installed a special hot-key in your copy of JBuilder, Alt-Tab. When you hit it, the VSS explorer pops up, and it works just like the explorer that VSS itself uses – it’s indistinguishable!”
Recently, another example popped up from an unexpected place. It turns out that there is a bug in my beloved IntelliJ and WebLogic, but only when you are doing distributed transactions and messaging. My colleague spent the better part of a day trying to resolve that little nasty bug.
The snake oil hiding in the shadows here is the promise of integration sold by tool vendors. IDE’s try to encompass more and more. Visual Studio has always been successful with this (especially if you use all Microsoft technologies) without achieving a truly great code experience. Visual Studio.NET 2003 is a third world country compared the scarily intuitive IntelliJ, which is the Rolls Royce of IDEs. VS.NET 2005 is better, but still not up to IntelliJ’s standard. Borland tried to take this to the extreme conclusion with its Software Delivery Optimization suite, which tried to bind together requirements gathering, version control, coding, deployment, and monitoring into a single environment. This vision yields an awesome productivity gain as long as the integration is flawless. However, integration at that level is never flawless, meaning that you spend as much time (and considerably more frustration) trying to figure out why something that should be working isn’t, only to find out that it actually is working but the integration is obscuring the results.
Some integration is good – that’s why we have integrated development environments. However, there is a fine line where vendors try to go too far and end up lessening productivity rather than enhancing it. The problem is that tool vendors are trying to create monolithic environments. I suspect that Visual Studio in all its incarnations may be the culprit here – everyone is trying to replicate that environment. Finding the fine line between integration vs. stand-alone tools is tough and going to get tougher, as vendors produce more and more immersive environments to get you to buy into their integration strategy.
Someone has done this exactly right. In the next Technology Snake Oil (Drowning in Tools), I’ll talk about that.
Subscribe to:
Post Comments (Atom)
3 comments:
Like most things, tool integration is fine -- up to a point. At work, I use W2K, Eclipse and CVS, at home Debian, Eclipse and Subversion; hardly notice the difference. Same IDE, (almost) the same interaction. No hassle (well, almost no hassle). I spend hardly any time on futzing with the itegration part -- just get on with it and adapt to the oddities and quirks. In the end, it's more about your attitude; getting your working environment functional is important. fussing over details is not.
Eclipse is actually a perfect example of what I'm talking about. Clearly, the benefit of Eclipse is the plug-in architecture. Haven't you ever fought with a plug-in, thinking that it is doing what is advertised, only to find out that it's not? The first Subversion plug-ins for Eclipse were classic examples, reporting corruptions and failed check-ins erroneously.
If you have indeed found a perfectly solid working set, you are fortunate. However, I think that's rarer than anyone admits. And don't futz with it!
No doubt I agree completely the worst part is when the PM or managers buy the snake oil thinking that the project pace will pickup. It in fact slows down. Its almost like people don't want to admit that with complicated projects it just takes a while and the tools are quite imperfect.
Post a Comment