LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

How to Avoid Software Black Holes


Scott Rosenberg discusses ‘Chandler’ and how to successfully develop software

By David Worthington
May 1, 2007 — 
Some people dream in color; others dream in black and white. And then there are those among us who dream in code. Salon.com founder Scott Rosenberg spent three years trailing an assemblage of some of the world’s most legendary programmers, led by Mitch Kapor, as they attempted to revolutionize how we manage personal information.

Kapor’s Open Source Applications Foundation (OSAF) led the charge to create an open source alternative to Microsoft Outlook, which it named Chandler, after Kapor’s dog. With millions of dollars of donors’ and Kapor’s money spent and more than 4,732 bugs filed, Chandler remains unfinished. SD Times sat down with Rosenberg to discuss the topics raised in his book “Dreaming in Code” and the lessons he took away from his experience.

SD Times: Were there too many cooks in the kitchen at OSAF? In other words, did engineers have too much say?

Scott Rosenberg: There are a lot of different ways of doing a diagnosis of the problems at Chandler. There are people [who] have read the book and said, “Well, the problem is that it is a classic visionary problem.” Kapor had the vision and the resources to indulge himself; there were fewer constraints.

I don’t think that [having too many cooks in the kitchen] is the conclusion I have drawn. You have a project unlike other open source projects, that was being led by someone who is not primarily a programmer, whereas open source projects are much more typically driven by programmers.

How can engineers and business people communicate successfully with one another?

[Miscommunication is] the primary interface of failure. On the side of the engineers, or programmers, you have this constant hunger for specificity, for detail and finality. That is what the engineer wants, because if things are specific enough, engineers can go off and build them. If they are detailed enough, the engineers don’t always have to be filling in the blanks, and if they are final enough, they don’t have to always be worrying about constant changes.

That is what they want. The problem is that I have yet to encounter any software project that came anywhere close to fulfilling any of those conditions. It’s just not the world we live in. And so the question really becomes, given those conditions are just not achievable, how do we communicate in that imperfect environment?

The answers that you’ll find [methodologies with specific prescriptions] at the root of most of them are a handful of basic principles that are not even specific to the field of software. They are the kinds of things you would encounter in any advice for people trying to make a family or public organization work better. Those principles are to communicate frequently, and listen to what the other person is telling you. Engineers are used to precise language. Sometimes an engineer will hear something a certain way, and then go and do something that they think they heard. A week later, the businessperson says, “I did not mean that at all!” and a week’s work is lost. That might have been avoided if they spoke frequently.

Are there any pitfalls to avoid?

It is also important to be careful with terminology and vocabulary. Something could mean one thing to a programmer, and [another] thing entirely different to a nonprogrammer or business user. There can be big black holes of disaster awaiting you there, if you are not careful. It is a hugely important undertaking that should be done very carefully.

Working from prototypes and dealing with things that are partially functioning, so that business people can have something to go on, provides more clarity [than an abstract product]. The Chandler team spent too much time on the abstract. Getting something to people sooner, rather than later, provides better opportunities for course correction.

Is Linus Torvalds correct in his assessment that you should never plan to do a big project…that you should start small and, with luck, the project will grow?

It is an amazing observation. There is an old proverb that a journey of 1,000 miles begins with a single step. A 1,000 mile journey in software can be so daunting because of the amount of complexity involved. If you try to get your head around all of that, you will be discouraged and have a hard time getting started.

Keep your mind on a small and achievable goal. It is a variation on the incremental principle [of software development] that turns up in various ways like agile [processes] and Extreme Programming. It’s a principle that applies to any ambitious creative act. The World Wide Web was built on what programmers thought was crude and bad technology. But one quality made it right: It was simple and easy for people to start using. I place a lot of faith in simplicity.

What lessons can open source developers take away from Chandler?

Chandler’s place in open source is kind of unique, because it is open source in that code is available, but it has been very atypical in being a product that has been worked on by a team functioning like a startup. Most successful OS projects are really, truly distributed volunteer networks.

The problems [Chandler] set out to solve would be good problems to solve. The big lesson, that the participants in Chandler would not argue with, is that the lesson is to put out a small piece of a product that is useful enough to inspire people. Do it earlier, rather than later. Chandler spent a long time doing infrastructure work, and at some point realized that the direction was wrong.

They refocused around the calendar, and if they had done that at the beginning, they would be at a different place now.

In your opinion, would Chandler have succeeded if it had been developed as commercial software?

Well, the difference there is that the story would have been different if they had had a tight budget and were a more traditional startup. Constraints like budgets serve as a goad to get things done. Certainly, one of the factors in how long Chandler has taken is the open-ended nature of Kapor’s commitment. He has plenty of money and wants to see it happen.

He might have certain limits, but [the constraints] are certainly not anywhere as near restrictive as a more common business decision. That, to me, is more the issue than the difference between commercial and open source licensing. If Chandler has some greater limits on time and money, that may have helped focus their work faster, for sure. It is the same case, whether it was open source or commercial.


Share this link: http://www.sdtimes.com/link/30567
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading