November 14, 2006

November 11, 2006

The Myth of components

Article after article has been written that indicates that people can piece together software from components. This is a fallacy that has come back to haunt developer after developer. While it is true that some fairly simple modules can be linked together, the higher level pieces can't be, despite all the wishings of management all around the world.

Often you hear the word "integration" - somehow that benign word is supposed to convey the fact that its possible to mash two systems together. Let me direct you to a link
that may help to explain the philosophical problem that "integration" hides.

http://www.joelonsoftware.com/articles/LeakyAbstractions.html

So, why does integration not really work? Because of the number of connections required to make it work.

Suppose for example, that you try to link a ticket system with a source code system. You have two links, one from the ticket system one to the source code system. This is a simplification - in fact there are likely two sets of underlying data sources that need to be integrated on a table by table basis. Now suppose that you want to tie
this into a project management system. Now, you have 6 links, e.g. Ticket to Source, Source to Ticket,
Ticket to Project Management, Project Management to Ticket, Project Management to Source, and Source to Project Management. As you add components, e.g. mailing lists, qa, feature management the complexity grows factorially, not just exponentially, or additively. The higher the complexity, the more difficult to program, the more difficult to debug, the more difficult to maintain. Eventually the complexity is beyond the level human beings can manage; 9 times out of 10 the complexity is beyond the resources available to manage the project.

This is why company after company that has tried to maintain separate systems for their development needs eventually hit a wall... They resort to human beings to try to keep the data up to date in the various systems. The true cost of this inability to integrate is staggering when you begin to calculate salaries and lost revenue and loss of face.

Group Commons has approached this with the view that all of these systems need to be under a single platform. We have attempted to side step the complexity problem by building the system integrated from the beginning.

June 27, 2006

Community Junkie!

I'm afraid my partner is becoming a community junkie.... he's been working on adding about 15 new orgs each day to group commons. As he does it he comes up with enhancements, better ways to do things, and hits minor issues along the way. He's totally hooked on the quick fix - and because of the way we have written the application most of the time he gets a fix in minutes.
And a fix in minutes means another community in minutes...

May 24, 2006

Blogs as Carriers of Commerce

Now. . . , take the blog idea one big step further and imagine it actually carrying tasks, collaborations, settlements -- not just chitty chat (like so many blogs) but actual work and earning people can do. Yes, current blogs enable adding content; what about adding my value and getting paid for what I add to a task?

May 23, 2006

Words from Group Commons Founders

Here we hope to offer you a weekly/bi-weekly comment on online community building. We believe that our insights will help you build your organisation and your online collaboration efforts into better solutions for your organisation.

Here we plan to touch the tip of the iceberg. No amount of us sharing will equal the experience that you will go through in the process of creating an online community. We can only hope to make your process less painful than our experiences. We can only hope to help you avoid the pitfalls.

Experiences in Community Collaboration

Community Collaboration is hard. Online community collaboration is even hard. That fact becomes evident about 3 days into the process of putting together an online community. First there is a set of technology issues, then there is a set of people issues, then there are a set of adoption issues, and after that is the "keeping it alive" issue.

Not a single one of these is simple.

Technology issues include choosing your platform - and matching the needs of your organisation to the platform.

People will invariably offer you alternatives - and tell you that they have the simple clear, 100% solution. Every time that you dig deeper into what they offer, you'll find that isn't quite true. The politics involved in choosing technology solutions can bog the process down to the point where no progress can actually be made.

Adoption issues loom early. You may have the best technology in the world, but if you don't get people to use it - its worth ZERO. Getting people to adopt a technology means introducing people to something new; most people are adverse to new technology to begin with. Likely the introduction will also involve a change in processes as well - furthering the alienation.

Ok, lets say you have managed to convince some early adopters to sign up. Now you need to worry over keeping the life blood of the organisation flowing. Here's a hint - the early adopters will drop off - the hope is you can hold onto a core piece of them - and that they will inspire the second wave to keep going.

Words from a Group Commons Founder,
Tom Riemer