developing software for your site

When you can't find a commercial application that suits your needs or when you want to build a tool that will differentiate you from your competitors you'll find yourself developing software for your site. Whether it's a tool for your users (like a search engine) or the site creators (like a content-management system), the development process is the same. And it's a challenge.

You'll need a product manager, an engineer, and a designer to come together and design the application. And even when team members are skilled, motivated, and focused on the same goal, they face enormous hurdles: They don't think the same way, they don't work the same way, and they don't even speak the same language. And that, as they say in Engineerese, is "non-trivial."

So it helps to begin this process with a mutual understanding of what you're trying to accomplish, and how you plan to get it done.

4 keys to application development:

1. Clearly define the problem.

2. Limit the scope.

3. Let the application evolve.

4. Collaborate.

clearly define the problem Before you begin work on a software application, you have to define the problem it will solve and be specific. Some of the saddest stories in software development began with a vague, open-ended product idea which the engineer had to interpret.

"An ill-defined product makes me extremely nervous," says Noah Mercer. "An ill-defined product with no one around to define it makes me more nervous. An ill-defined product with someone around to define it who doesn't have the time or the skills to do it makes me want to run away in panic."

So the first challenge is to nail down the specific problem you're trying to solve with the application. Then sit down with the engineer (and a designer), and work through the details.

"What most engineers like is definition," Mercer explains. But that doesn't mean writing a description of a product and asking them to build it. "Engineers often like and should be involved in the definition phase," he says. "So don't just go off and define the product and hand it to them. That's not a good idea. But it's a terrible idea to go off, halfway define it, then hand it off without involving them. That's a recipe for disaster."

This is your nightmare: The engineer delivers a product that cleverly solves the wrong problem.

The problem with handing off a vague request is not only that it annoys engineers, but it prevents them from doing their jobs well. For starters, they can't give you a reasonable estimate for time or costs on a product that's only partially described. "You're going to get back an estimate that doesn't take any of the details into account," Mercer says.

The other problem is that the engineer can't read your mind. He won't necessarily know how to interpret your impressionistic request. And if you're not clear about what you want, you may get something you don't need.

Mercer offers an example of how this process goes wrong: "Let's say you want an application that will organize your grocery list, so that when you go into the supermarket, you can go through aisle 1, 2, 3, 4, 5, 6, 7, then checkout instead of aisle 1, aisle 3, aisle 2, aisle 7, aisle 5, aisle 3, aisle 1."

"A really bad product definition would be, 'Hey, I just need something that organizes my grocery list so I can go through the aisles and pick up the stuff I want.' Literally, some people do that. They give the engineer this simplistic description of what they want, and expect to get back a finished product."

"This is fine," he says, "as the beginning of a collaboration. But it's not sufficient on its own." The devil, as they say, is in the details.

"The programmer starts digging into it, and he realizes, 'Well, we've got a few problems here. Do you want it to work with multiple grocery stores or do you have one grocery store in mind? Aisles are sometimes numbered differently there might be aisle 7A and 7B how do you want us to handle that? What about the row at the back where the dairy and the meat are, which isn't really an aisle? Do you want me to divide that up into the aisles that lead into it or should I assign it an arbitrary aisle? How do I handle that one?'"

"And so the person who thought that they were going to type their grocery list, and hit 'go' suddenly finds they have this 63-page web application with admin tools for setting up grocery stores and SKU product numbers for inputting item data."

This, you see, is your development nightmare: The engineer delivers a product that cleverly solves the wrong problem.

limit the scope One of the biggest mistakes software teams make (even teams of experienced developers at well-known companies) is trying to solve too many problems at once.

To prevent your project's scope from creeping endlessly outward, it helps to focus on a particular user facing a particular problem. Your goal, says engineer and usability expert Indi Young, is to "form a mental model of what the user is trying to get done."

The biggest mistake software teams make is trying to solve too many problems at once.

"But before you can form a mental model, you have to figure out the scope of what the user is trying to accomplish," she explains. "You can't form a mental model about really large things, just like you can't form communities around really vague topics."

Sometimes, a project's scope expands because team members can't make up their minds or don't agree on who the primary user is. But "scope creep" can also result from overzealous planning.

You'll pay the price for this kind of ambition. If you define a problem too broadly, you may create something that's too complex to finish and too complicated to use, or that doesn't quite solve anything for anyone.

"Software that's extremely flexible is often unusable," says Jim Morris, former director of software engineering for Fogdog sports, an early e-commerce company. "It's also really hard to launch. It's hard to finish it."

let the application evolve It's the most common mistake that rookies make: Launching a finished product.

The web gives you unprecedented opportunities to observe how an application is used and apply that learning to future versions, which can be released in quick succession. And if you over-design at the beginning, you may paint yourself into a corner, limiting your ability to change direction or improve upon what you have.

"You should design your system to evolve," explains Greg Dotson, Chief Information Officer of Guru. "A good application development company is constantly getting feedback from real users and incorporating that into the site. Feedback between users and the system is key."

This can be a hard adjustment for some product managers, who like to think through all the details before development begins. Dotson himself says he had to make that transition:

"I went through a phase in my career when I thought specifications were the best thing, because you do everything up front," Dotson explains. "It's always easier to identify an error up front than it is downstream."

"But what I've learned is that no matter how much you think about a problem, there are always things you don't consider. Business needs change. The world around you changes. There are so many things you can't anticipate. So a powerful benefit of developing on the web is that you can consciously plan to iterate on those things you didn't anticipate."

building the right team

To build a successful application, you first have to build the right team. Technical projects are best produced by a small, collaborative team with a clear objective and the authority to make product decisions.

This team should include the producer (or product manager, depending on your terminology), the lead engineer, and the designer or usability expert. Depending on the project, one or two other team members may be appropriate.

However, if this team isn't small, isn't collaborative, or isn't empowered, you're going to run into trouble. A team that's too big will have trouble scheduling meetings, maintaining consistent communal knowledge, and making decisions.

If the team isn't small, isn't collaborative, or isn't empowered, you're going to run into trouble.

A group that isn't collaborative will move too slowly, miss opportunities, and risk building a product that's completely off the mark. Location is one of the keys here. So try to assemble a group that works in the same place. The farther apart a team is geographically, the harder it will be to stay in sync. Even co-workers in the same office benefit from getting closer: You can set up a common workspace for the duration of the project. (See how to encourage collaboration, p. 330.)

Finally, a group that isn't empowered will waste a lot of time making decisions that will later be overturned resulting in lost momentum and ruined morale. Be sure that company stakeholders give their input early on. They should communicate their priorities, set clear goals for the project, and then get out of the way.

collaborate To create a successful web application, you need every team member engineers, designers, product managers (or business users) to bring their knowledge to the table in a way the others can understand.

"In my experience, the only successful applications have happened when there was mutual respect between the engineering department and the creative department."

Janice Fraser

But communicating across disciplines is a challenge. So the process works best when team members work closely, communicate openly, and consider each other partners in the development process.

"In my experience, the only successful applications have happened when there was mutual respect between the engineering department and the creative department," explains Janice Fraser, a partner with Adaptive Path. "The most disastrous happened when those two groups had animosity toward one another."

The goal, she says, is "to bridge the gap, and to develop tools so the two groups can communicate effectively in language that the other understands."

Managing a cross-disciplinary team?

setting goals for a company site, p. 14

managing a web team, p. 328

how to encourage collaboration, p. 330

how to run a brainstorming session, p. 326