Email was born sometime between 1965 and 1970, depending on how you define its genesis, and by 1980 it was considered by many to be the killer app. It drove the proliferation of PCs in the workplace and allowed people all over the world to work together.
SMS texting and tweeting can take some credit for email’s slow decline. However, it remains the most widely used application — just ask the U.S. government.
Even in tech-savvy cities, texters and tweeters account for only about a tenth of electronic communications recipients, according to GovDelivery, the largest provider of government-to-citizen communications.
In spite of its popularity with the general public, clunky old email certainly isn’t the fastest tool in the communications corral anymore, nor is it the most efficient.
“When you reach a ‘critical mass,’ even of two people, email just doesn’t work,” said Rosie Pongracz, director of product marketing at CollabNet, a California-based application lifecycle management (ALM) platform provider. “Enterprises need workflow management, and they need to document it.”
Email isn’t a project management tool; it wasn’t designed to be. So why do developers, who typically work as part of large, geographically dispersed teams — taking advantage of screaming fast transfer rates in almost all they do — still rely on email? Among email’s hard-to-ignore features are a quick, often free startup, and the fact that it is accessible to just about everyone.
The Allure of Cheap and Easy
“Whatever solution has the lowest barrier to entry, that’s the one the developers are using,” said Jeffrey Hammond, principal analyst at Forrester. “The easiest is email,” he said, noting that it’s “free, quick to get started, and it’s reliable.”
Well-known collaboration tools like Microsoft Sharepoint, Hammond pointed out, require someone to make a decision to buy a server, someone to approve the purchase, someone to administer the server and the solution, and a means to train users and require them to use the system.
“Even though in the end the solution might be a more productive, efficient one,” Hammond said, a lot of work is required to get the payoff — which should be a smoother, simpler method of collaboration. Meanwhile, email is too cheap, easy and obvious to ignore.
“Think about how developers work. They always have more stuff than they can do, they always [have more bugs than they can fix],” Hammond noted. “Whatever is easiest, fastest and most pragmatic is what they’ll pick.”
During projects, members of development teams like to remind each other that “you don’t want to change all the engines on the 747 while we’re in flight,” noted Hammond, who developed application development software for IBM and other organizations before joining Forrester.
“Doing too much simultaneously is too much risk. So if [email is] what you’ve been using, and it works well enough …, changing is going to increase risk.” Hammond said. “In general, developers don’t take risks if they don’t have to.”
Still, as collaborative tools creep out of development teams and into the mainstream, there will be fewer risks — and probably some pressure from workers who aren’t developers — to step outside of the in-box.
Not surprisingly, CollabNet, with 220 employees in seven offices worldwide, points to itself as a good example. Everyone in the company uses CollabNet for corporate collaboration.
“We eat our own dog food, as the saying goes,” Pongracz remarked. “We use [CollabNet] in marketing.” One of CollabNet’s biggest customers, Cap Gemini, has 35,000 users, Pongracz pointed out — and developers are in the minority there.
Collaboration Can Be Cheap and Easy Too
“Email is so easy and quick — but, again, when a team grows and a project grows … they can’t really use it,” said Richard Murray, CollabNet’s vice president of engineering.
Legacy tools like Borland were very expensive, Murray noted, but CollabNet is cheap — free, in fact — and easy.
“Little pockets of people” install and start using the product, Murray said.
“One of the reasons it proliferates is because of its cheapness,” he acknowledged. “Everyone out there has Subversion someplace.”
Email, the LCD
One possibly overlooked — and hard to change — factor that might help explain why more distributed teams don’t using the speediest online collaboration tools available is simply that we’re not all developers. By relying on group mailing lists and combinations of IM/email messaging, developers can invite less proficient users to join the process using a tool every user is comfortable with: email. It’s like the application version of a lowest common denominator.
“It really is standard. … Every tool sort of has an email [function] built in,” Ned Lilly, founder and CEO of xTuple, told LinuxInsider. “I think email is pretty much the lingua franca.”
Formerly OpenMFG, xTuple now offers open source enterprise resource planning — making xTuple itself the end product of collaborative software development.
Because it enjoys such familiarity, email can provide a painless introduction to the whole idea of online collaboration. Google Apps’ suite of Web-based collaborative tools, for example, features G-mail as a linchpin.
If It Ain’t Broke, Will They Fix It?
Collaborative software platforms and applications are supposed to improve information worker productivity and improve communication and organization across an organization. So perhaps the question is not, why do developers still rely on email, but what could entice them to rely on something else?
There are a couple of potential “game changers,” said Forrester’s Hammond.
Defect tracking and software change management (SCM) present a “hole in the middle of the process,” he said. “I don’t see a compelling open source [defect tracking system]. Bugzilla is about the best they can get.”
If a Twitter-like feature were integrated in SCM applications, Hammond said, it would probably be welcomed by developers.
Whatever is added to the process better be simple, warned Lilly, who said the success of xTuple depends on the organization listening to the development community.
“It almost seems like the closer you get to core developers the happier they are with a command line,” he told LinuxInsider. “They like plain text email. … For them, a lot of it is about simplicity and elegance. When you’re developing software, every extra character can slow you down. It’s another opportunity for human error or a typo.”
Loading ...
Interesting. Under the IBM Jazz initiative, https://jazz.net/ one of the offerings built on Jazz technologies is IBM Rational Team Concert, which provides defect tracking and configuration management capability. Team Concert embeds Lotus Sametime componentry for instant messaging and presence functionality, which provides twitter-like capability in real-time.