Its Not About the Cows

Opinion: Tech innovation should proceed from need, not hold fast to the past.

When I saw the news of Ciscos forthcoming TelePresence virtual meeting system, my first thought was, "Now theres a really well-paved cow path." For anyone building enterprise applications, Ciscos innovation is a cautionary example of the temptation to approximate the familiar, as closely as technology enables -- instead of starting afresh with a business need, and meeting it in the best way that new technology permits.

If that "cow path" phrase is new to you, it refers to the layout of streets in a city like Boston, with its quaint intersections at almost every imaginable angle. The layout of those streets, as you know if youve ever driven there, clearly wasnt designed to make traffic flow smoothly -- or based, for that matter, on any other high-level thinking of what would make an effective system. It was, or so the legend goes, created by taking the established paths from the citys agrarian past, and making incremental improvements to handle successive generations of transportation technology.

The result is a mess. It wouldnt matter if those were electric cars or even anti-gravity monorails running through that mess, it would still be a mess. Thats why systems need to be designed to achieve the best possible match between business problems and new capabilities, rather than using new capabilities to imitate old solutions.

You can see the results of "cow path" thinking in many aspects of many organizations. The notion, for example, that an effective management span is at most eight people under one manager dates back to when we were hunting (or fighting) in forests, and a team of more than eight people couldnt hear one leaders instructions. As the late Peter Drucker well noted, though, an orchestra conductor leads a group of several dozen, and that works because theres a broader allocation of specialized knowledge and personal responsibility.

If face-to-face meetings were considered the high point of organizational productivity, Id endorse the idea of throwing bandwidth and hardware at the task of migrating that process to cyberspace. I have to admit that "virtual table" meeting environments make for appealing scenes in telecom providers TV commercials of how well live tomorrow: virtual Thanksgiving dinner, anyone?

Even so, I dont for a moment miss the bad old days before I became a full-time telecommuter -- coming up on 18 years ago -- when I had to attend real meetings all the time. If you ask yourself, "What are the functions of a meeting?" -- and come up with a list like "Sharing information, establishing priorities, agreeing on responsibilities, and assigning actions to be taken" -- then wouldnt you agree that current technology offers much better ways to do most of these things than sitting around a table, real or virtual?

If you think of your goal as helping a development team write better code more quickly, youll come up with something like the collaboration tools in Suns Java Studio Enterprise. If you think of your goal as improving your process of new product definition and established product line management, youll come up with something like Sopheons Accolade and its Accelerator packages.

If you think of your goal as making it possible for dispersed teams to "have better meetings," youll come up with something like Ciscos solution. Great technology, no question. Productive application? Thats for you to decide.

Tell me where youve seen cows wandering at</a>


Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.