Having a discussion with Mark Smith from Virtual Methods started by comments about what kind of groove tools will succeed.

Mark: Obviously I 100% disagree with your comments about whether Groove Tool Vendors will succeed. The major problems I've got (apart from price/quality issues) with our larger competitors is that they treat software development as almost a solo activity, carried out in an environment tighlty bound to a developer IDE. Your link to the Infoworld Booch interview shows that other firms are pushing in the Analyst<->Designer<->Developer direction, as borne out by their most recent product releases. My view is that the other direction-Customer<->Analyst<->Project Manager -is being neglected. I also know from direct personal experience that a Groove space provides a better way of specifying and designing software than the current hotch-potch of email, Word documents, scribbled notes, meeting minutes and so forth. Would you agree that the integration of requirements, design and project management can only make softeare projects less painful?

It seems we’re talking about two different issues – first being whether Groove tool vendors will succeed and the second being the vision and the target market of UMLTool. Obviously, its not my place to critique UMLTool and Mark's vision behind it. I sincerely wish Virtual Methods luck making it a hit! I’ve only used UMLTool as an example of a new application that knows collaboration in an established market of feature-rich tools that don’t know collaboration. Fair?
I think we’re in agreement that current software development tools simply lack collaboration feature set. Yes, software development is highly collaborative process that involves many different types of stakeholders as Mark points out. I would pay to have the better collaboration tools for software developers. But I would only pay if those tools don’t take away my other favorite features. In my work I use UML using Visio. I’ve selected this tool because it is feature rich, integrates with office, stable, gets the job done, blah blah blah. But this tool doesn’t know collaboration. So naturally, I turn to UMLTool. Will I end of switching from Visio to UMLTool? I will, only if UMLTool doesn’t take away all of my other favorite features present in Visio.
I believe this very logic will be used by majority of buyers of Groove Tools. If users find groove tools sub-standard in areas other than collaboration, I believe they will opt to use their current tools and simply end up using Groove for file sharing. Same logic will apply to Groove-created tools like calendar. What would Outlook user prefer while arranging a meeting with a partner: seeing their shared calendar directly in Outlook or switching to different UI of Groove, going in the shared calendar and trying to figure out the conflicts with his/hers personal Outlook calendar?
Would you agree that sub-standard tools that know collaboration are less valuable to the user than full-featured tools with added collaboration features?

While looking for info in groove integration exampes I stumbled on this post:

Date Posted: May/10/2002 11:02 AM

Posted By: philking (Member)

Moderator,

Also checked the controller and noted that is shutdown fine there. The sample controller code is too simplistic to use as any sort of meaningful test. Note that opening tools as per the sample doesn't allow the tools to work at all!

If GN is serious about selling Groove for controller use then that comittment should be evident through the samples and adequate beta testing in the contoller environment. This would also be an excellent test for the API classes which like any good class structure need to work independently of any UI or Tranceiver specifics.

Controller apps could end up representing a huge slice of the total user base of Groove technology. Currently the transceiver and standard UI components are far too limiting for powerful app developent. This shows through all tools currently available and the time, effort and cost to produce such mediocre functionality. The end result is that users come away less than impressed with Groove. Indeed many are reluctant to use it because the interface and functionality is far inferior to which users are accustomed in most windows apps these days. To understand why, one can simply look at the ListView component. It's functionality is so crude it wouldn't register on a feature comparison chart up against mature ActiveX grid controls on the market today. Sure we can sort of wrap ActiveX in tools but that does NOT deliver the performance or functionality of a component designed to be hosted in an ActiveX container totally integrated into COM.

Personally I believe developing Groove apps in a mature environement supporting native ActiveX containment is the way to go. Rich and diverse functionality can be delivered at RAD speeds providing the API doesn't choke developers efforts along the way.

GN marketers need to remember that no matter what hosts Groove technology, the Tranceiver or a Controller, a Groove license sale is a SALE! Controllers need more attention. Please bring this crucial issue up with GN management and help Groove proliferate to every desktop.

Still with grand hopes for Groove ...
Phil


05/10/2002 11:18:34

This post resonates with my concerns about groove's busines model. As much as I'm excited about groove's technology, collaboration should remain a feature of a desktop application. Collaboration framework/platrofm like groove must avoid making ISVs re-write their existing applications just to enable collaborative workflows. Even less groove should try to re-write those apps themselves!

I'm sure we all want to see superb collaboration functionality in something like Adobe Photoshop to take one example. Does groove seriously beleive that adobe will re-write their system to be hosted inside groove's UI?

What's more worrisome is the fact that some of groove partners seem to buy this strategy. They seem to beleive that groove is their golden opportunity to leapfrog established competition.
Let me pick on Virtual Methods UML Tool. Forget collaboration for a second. How does the UML modeling funtionality of this editor compares with competition (Visio, Rational Rose)? I think UMLTool is doomed because of very strong compatition it faces.

The bottom line: Fantastic technology like groove will not cause people to abandon their favorite tools. Groove should pay more attention to integration into existing applications.

Just read Understanding GXA by Don Box. Very nice brief (8 pages) overview of a gigantic undertaking of building infrastructure protocols for web services. For people interested in WS protocol, i definetely recomment reading this article before diving in detail of any specific any specific protocol.

"Spend A Day with .NET" Coding Contest
What a wonderful idea by Chris Sells. So I still have 3 days to decide if I want to participate!

Paul Krill announces that Microsoft readies specifications compliance kit for Web services. It seems that with those tools in place the stage is set to build entirely standards-based groove clone. That would be a secure (WS-Security) data sharing (WS-Attachments) that can work though firewalls (WS-Routing). Of course this is highly speculative. Need to learn more about this...

Brian Fonseca writes about application-level firewalls.
My prediction: there's absolutely no choice for firewall vendors to go in this direction. Web Services would represent a major target for attack. The richer services become, the more attack-prone they will be. The pain will only start with 'corporate' web services, but sprread on personal workstations as people employ more and more P2P tools.

High-Tech Ventures by Gordon Bell

After 11 years this book remains a great resource for everyone who evaluates a starup's health or is thinking about starting a business. The book contains a very comprehensive set of really good questions that evaluate the business in every dimention critical to its success. The success is assured if you have the right answers to all of the test questions presented in the book. Great resource for high-tech enterpreneurs, VCs, hires.

Word of caution though. This book isn't really about how to build a successfull business. It's more about how to tell if a given business (or a business decision) is to be successful. Most of the case studies in the book are really annotated examples of falures, as oppose to examples to follow

Highly recommended.

Assuming that Rational is hard at work on the stuff Grady Booch sees in the future stay tuned for some great developer tools! Just what i think every developer really needs.
"The idea of bringing the UML as a higher-level language that transcends most of our textual languages and enables us to do both very good code generation as well as reverse engineering and perhaps even [brings us] to the point of direct executability in some UML models." [Booch]

Tom Sullivan writes about UML 2.0 spec.
Looks like they are adding more riguor and fine details to the already-too-detailed language. In years of informally using UML I've never seen people actually being successfull of using the language as it was originally intended - formal definition of a software system. Apart informal brainstorming, another great use of UML is communicating design patterns.
Where I've seen UML fall flat is when people attempt to capture an entire architecture in a static UML model. Such model will inevitabely go obsolete and out of data with the code.
IMHO what developers miss is some real practical tools that use UML beyound its informal whiteboard usage. It would be great to have a lightweight way to link the code and the UML model. Once the two are linked, ether the code or the model can be edited.

Jon Udell's blog

Jon Udell writes about RSS aggregators. If the phenomenon of blogging continues, soon many people will come to realize that they can use some automation of their daily routine of reading other people's blogs. Also, more and more people will "get" the idea of syndicating news posts.
We're clearly at the very beginning of this development. The tools like Aggie are pretty primitive, so there's lots of opportunities outthere. Email, IM, blog writing, news reading will come together in a few years in a very powerful way and the discuvery of RSS is a good step in that direction.

Today's essay by Ray Ozzie has led me to his personal blog.
In an excellent note called Architecture Matters: The Rebirth of Public Discussion he argues that blog design pattern naturally solves the signal-to-noise problem of other means of online communication such as newsgroups and other similar services. This note has led me to thinking about "blog design pattern":
While I'm facinated by the phenomenon of weblogs I currently see a few little bit of an issue with blog design. In order to conduct an effective and fruiful dialog online, all parties have to be notified when a reply to the original post has become available. That's the basis of opration of mailing list, newsgroups and other 'conventional' methods of online communication. When a conversation is spread across many different blogs, it is difficult to see how a constructive conversation can be conducted when an author isn't notified that someone is replying to his or her post. It would not terribly difficult to build tools to solve this issue, but I'm not aware of any existing today.
Secondly, vast majority of blogs are personal. And a persone usually has to deside which ones to follow. This consequence of blog design pattern can easily lead to ideas being burried within a closed circle of friends.