Citicorp and Santa Fe Institute

In Complexity, Mitchell Waldrop writes about how the CEO of Citicorp, John Reed, met with the people that would later found the Santa Fe Institute to see whether they could help each other: money was needed to start up the institute, and Citicorp was in need of help understanding the seemingly chaotic global economic system.

Waldrop writes:

As dearly as [George] Cowan and company wanted to see some of Citicorp’s money, they also wanted to make it very clear to Reed that they couldn’t promise him a miracle. Yes, they had some ideas that might be helpful. But this was a high-risk enterprise that might not lead anywhere. The last thing the fledgling institute needed was a lot of inflated expectations and hype [...].

Reed said he understood completely. “My view was that I didn’t think we were going to get something hard and concrete,” he recalls. He just wanted some new ideas. So he promised not to put a time limit on the product, or even to define a deliverable product. If Santa Fe just got started on the job and made visible progress from year to year, that would be enough.

Now, I don’t know how much funding Citicorp has provided the institute with over the years, but this attitude fascinated me. It’s open and characterized by trust – something that is very seldom seen in software projects, where both parties often are very protectionist: the developers don’t want to make any promises and are reluctant to make estimates, or at least inclined to add a good dosage of overhead in case the customer proves to be unpredictable regarding the requirements.

The customer, in turn, often wants to nail down both the scope and the deadline, but at the same time is reluctant to participate to any larger extent in the project, save for occasional status meetings where he wants to hear that everything proceeds as planned.

It’s important to realize that software projects are explorations. Not of the dignity that the Santa Fe Institute was facing, but still – it’s about exploring the problem space and inventing working solutions, avoiding pitfalls in the form of misunderstandings regarding things that aren’t articulated in requirements specifications and meetings, because they are so common in the day-to-day work that they aren’t thought of as significant.

Both parties need to agree on that they are equally interested in the success of the project, but that few promises can be made early in the beginning, and that few things can be said with absolute certainty; they need to agree to collaborate closely and to pay close attention to the progress. If the project doesn’t proceed satisfactorily (for any part), it’s the responsibility of both parties to resolve it, together. Software development is not war.

(The Santa Fe Institute are blogging, by the way: Complex Interactive Networks; via Rajesh Babu.)