The Right Way to Write Code - Jim Sims

In most companies, the front-end design process alone takes six to nine months. In our Rapid Solutions Workshop we do it in three weeks. The time compression is incredible. It can be an ugly, frightening experience at first. You go through a valley of despair. Users are laying out what they need, and the technology people want to crawl into a hole. Our people guide them through what features make economic sense, what you can tie to real economic benefits. We've been through hundreds of these things in the last five years. I tell you, the results are amazing.

The second problem is that most applications aren't considered urgent enough to command serious attention. We build only what we call "numerator" applications -- software designed to generate revenue rather than cut costs. Our systems relate to customer service, order fulfillment, sales, distribution. They're designed to increase market share and get products to market faster. Senior executives will get very involved in those projects. And users will stay involved as the system gets designed. Our focus on the numerator helps us, too. At the end of a Rapid Solutions Workshop, a client has two choices: start building the system tomorrow or spend six months sorting through competitive bids. I say to them, "Do you really want to spend six months on bids when you know this application will generate returns of $2 million a month? Are you prepared to give up $12 million on the chance you might save a few hundred thousand dollars on development costs?" Remember, if you don't capture those returns, they're gone. You never get them back.

What are some other techniques you use to accelerate the software-development process?

We write most of our applications -- not all, but most -- using object-oriented software. We're always asking ourselves, "How do we reuse objects we've created for other applications?" We use an internal networking system called KnowledgeShare to share objects. Today, technology we create in Amsterdam gets used in applications we're building in California.

But KnowledgeShare is having an even bigger impact than reusing software. It's allowing us to reuse knowledge itself. We share everything: technical documentation, presentations, lessons from individual projects. It's all about making quick connections: "I just finished a project for a client. Here are the 17 lessons I learned. Before you start on your project, why don't you look at them?" The most important knowledge is what you learned today that someone else can apply tomorrow.

Recently I was on a trip to Ireland with Fergal Mullen, our director of mergers and acquisitions. In the middle of the trip we met a potential client in the insurance business. He asked us to visit the next morning and make a presentation. We literally had to put it together overnight. Fergal went into KnowledgeShare, discovered something we'd done on the West Coast a few days before, downloaded the presentation and all the documents behind it, and stayed up late that night putting it together. We walked in the next morning and knew exactly what we were doing.

The speed is just incredible -- taking work that had been created in California and using it in Ireland a few days later. Once people see this kind of impact, they become religious about sharing knowledge.