The Right Way to Write Code - Jim Sims

Focusing on speed doesn't change just how people work -- although we certainly work differently from most companies. Speed changes all the fundamentals of business: how we train our people, how we relate to our clients, how we manage projects.

Forget about writing software for a moment. Think about hiring. Five years ago, this company had about 100 employees. Today we're adding nearly that many people every month. We've established a hiring cycle of 60 days between when we recognize a need and when a new hire reports for duty. That timetable -- that focus on speed -- forces us to be creative and disciplined about how we recruit, interview, and evaluate people.

Or think about strategy. We have a plan to be in 70 offices by the year 2000; we'll be in more than 30 by the end of this year. We've declared that any new office, anywhere in the world, must be profitable within nine months. We've developed a complete methodology to do this -- every step from the moment you think about opening an office to when it's fully staffed by a local team. The time dimension has shaped how we grow the business.

Let's stay with the business basics. What are some other fundamentals that change when you compete on time?

You have to manage the fallout from speed. We have 1,300 people working on 200 or 300 projects a year. They're moving around all the time, working with different clients and project managers. That's great; it's one of the benefits of working fast. A typical project lasts about six months. So if you've been here for two years, you've worked on four or five major projects. That's a real plus for young people developing their careers.

But we don't want a company of nomads who migrate from project to project. That's why we created the role of resource manager, senior people who act as career guides and mentors. It's a voluntary role, but most people consider it a privilege. Resource managers watch out for the young people they advise, check on their development, point them to interesting work. They also have a voice in who gets assigned to which projects. They'll tell a project manager, "I know two people who are just about to come off a team. They'd be great for your project."

That's so important. If we're not developing our people, they're going to leave. I would if I were them. If you're 28 years old and you've been at a company for five years, and what you're doing hasn't changed dramatically, it's a sign that you should move on.

It's interesting you mention 28-year-olds. So much of this company's personality revolves around youth. Are people in their twenties the only ones who can work this way?

It's not about age; it's about attitude. We call it Generation X thinking. Young people today are more different from their baby-boomer parents than the baby boomers were from their parents. They're interested in adding new capabilities and staying mobile. It's important to do work that's "cool." They want time and attention from their supervisors. That's more important than money. They also love surprises and fun. They don't want to know what's going to happen every day. They want to come into the office and see a birthday cake, have a spontaneous celebration, get a new assignment.

We hired lots of very young people early in our history. We figured it would be easier to train them in our methodologies than to retrain more senior people from other companies. Pretty quickly we realized that these people had very strong ideas about how they wanted to work, and that those ideas were absolutely pervasive. Many of us came from different environments, different kinds of companies. As senior managers, we had to decide whether we were going to adapt ourselves to these young people's thinking or ask them to think like us. We made the right choice. Their personal attributes are very conducive to building a fast-growing company.

Let's talk about writing software. It's the black hole of the new economy. Companies spend $250 billion a year on information-technology projects, and only 16% of them are completed on time and on budget. What's the problem?

The first thing to understand is that 90% of the problems in software happen before you write the first line of code. Applications are late because the people building them don't know what the users really want -- which means they keep changing. Or they're late because users ask for every feature they can imagine on the theory that if they don't get it now, they'll never get it.