Distributed Development

Vol. 1 No. 9 – December/January 2003-2004

Distributed Development

Interviews

A Conversation with Steve Hagan

Oracle Corporation, which bills itself as the world's largest enterprise software company, with $10 billion in revenues, some 40,000 employees, and operations in 60 countries, has ample opportunity to put distributed development to the test. Among those on the front lines of Oracle's distributed effort is Steve Hagan, the engineering vice president of the Server Technologies division, based at Oracle's New England Development Center in Nashua, New Hampshire, located clear across the country from Oracle's Redwood Shores, California, headquarters.

A Conversation with Steve Hagan

Oracle Corporation, which bills itself as the world’s largest enterprise software company, with $10 billion in revenues, some 40,000 employees, and operations in 60 countries, has ample opportunity to put distributed development to the test. Among those on the front lines of Oracle’s distributed effort is Steve Hagan, the engineering vice president of the Server Technologies division, based at Oracle’s New England Development Center in Nashua, New Hampshire, located clear across the country from Oracle’s Redwood Shores, California, headquarters.

Hagan is in charge of several portions of the Oracle 9i database server development, including disaster recovery, utilities, migration, multimedia, and extensible databases, as well as portions of the iAS mid-tier application server. There are more than 400 people at the Nashua location.

Articles

Black Box Debugging

Modern software development practices build applications as a collection of collaborating components. Unlike older practices that linked compiled components into a single monolithic application, modern executables are made up of any number of executable components that exist as separate binary files.

Black Box Debugging
JAMES A. WHITTAKER, FLORIDA INSTITUTE OF TECHNOLOGY
HERBERT H. THOMPSON, SECURITY INNOVATION

It’s all about what takes place at the boundary of an application.

Modern software development practices build applications as a collection of collaborating components. Unlike older practices that linked compiled components into a single monolithic application, modern executables are made up of any number of executable components that exist as separate binary files.

This design means that as an application component needs resources from another component, calls are made to transfer control or data from one component to another. Thus, we can observe externally visible application behaviors by watching the activity that occurs across the boundaries of the application’s constituent components.

by James A. Whittaker, Herbert H. Thompson

Building Collaboration into IDEs

Software development is rarely a solo coding effort. More often, it is a collaborative process, with teams of developers working together to design solutions and produce quality code. The members of these close-knit teams often look at one another's code, collectively make plans about how to proceed, and even fix each other's bugs when necessary. Teamwork does not stop there, however. An extended team may include project managers, testers, architects, designers, writers, and other specialists, as well as other programming teams. Programmers also interact with the community of developers outside their organization to obtain advice, code snippets, and a general understanding of what works and what doesn't.

Building Collaboration into IDEs
LI-TE CHENG, IBM RESEARCH
CLEIDSON R. B. DE SOUZA, UNIVERSITY OF CALIFORNIA, IRVINE, AND FEDERAL UNIVERSITY OF PARÁ, BRAZIL
SUSANNE HUPFER, IBM RESEARCH
JOHN PATTERSON, IBM RESEARCH
STEVEN ROSS, IBM RESEARCH

Edit>Compile>Run>Debug>Collaborate?

Software development is rarely a solo coding effort. More often, it is a collaborative process, with teams of developers working together to design solutions and produce quality code. The members of these close-knit teams often look at one another’s code, collectively make plans about how to proceed, and even fix each other’s bugs when necessary. Teamwork does not stop there, however. An extended team may include project managers, testers, architects, designers, writers, and other specialists, as well as other programming teams. Programmers also interact with the community of developers outside their organization to obtain advice, code snippets, and a general understanding of what works and what doesn’t.

Despite its benefits, collaboration can be time-consuming and problematic. Studies show that the escalating number of meetings, e-mails, discussions, source-control management tasks, and other coordination efforts are leaving less than half of the workday to do any real coding. But we cannot simply walk away from meetings, turn off our e-mail, and hide in our cubes. We cannot ignore the trend toward an increasingly interconnected world where development teams are distributed around the globe. Indeed, a major problem in software development is the breakdown in communication and coordination among developers.

by Li-Te Cheng, Cleidson R.B. de Souza, Susanne Hupfer, John Patterson, Steven Ross

Culture Surprises in Remote Software Development Teams

Technology has made it possible for organizations to construct teams of people who are not in the same location, adopting what one company calls "virtual collocation." Worldwide groups of software developers, financial analysts, automobile designers, consultants, pricing analysts, and researchers are examples of teams that work together from disparate locations, using a variety of collaboration technologies that allow communication across space and time.

Culture Surprises in Remote Software Development Teams
JUDITH S. OLSON, UNIVERSITY OF MICHIGAN
GARY M. OLSON, UNIVERSITY OF MICHIGAN AND COLLABORATORY FOR RESEARCH ON ELECTRONIC WORK

“When in Rome” doesn’t help when your team crosses time zones—and your deadline doesn’t.

Technology has made it possible for organizations to construct teams of people who are not in the same location, adopting what one company calls “virtual collocation.”1 Worldwide groups of software developers, financial analysts, automobile designers, consultants, pricing analysts, and researchers are examples of teams that work together from disparate locations, using a variety of collaboration technologies that allow communication across space and time.

Although solving the problems of space and time is difficult, these are not the only issues. Work that takes place over long distances means that communication will often involve different cultures. Participants may be surprised by such interactions because they have not considered various cultural differences and how they impact the daily work of long-distance teams. Our own culture is invisible to us. “We don’t see our own ways of doing things as conditioned in the cradle,” writes Esther Wanning, author of Culture Shock! USA. “We see them as correct, and we conclude that people from other countries have grave failings.”2

by Judith S. Olson, Gary M. Olson

Distributed Development: Lessons Learned

Delivery of a technology-based project is challenging, even under well-contained, familiar circumstances. And a tight-knit team can be a major factor in success. It is no mystery, therefore, why most small, new technology teams opt to work in a garage (at times literally). Keeping the focus of everyone's energy on the development task at hand means a minimum of non-engineering overhead.

Distributed Development Lessons Learned
MICHAEL TURNLUND, CISCO SYSTEMS

Why repeat the mistakes of the past if you don’t have to?

Delivery of a technology-based project is challenging, even under well-contained, familiar circumstances. And a tight-knit team can be a major factor in success. It is no mystery, therefore, why most small, new technology teams opt to work in a garage (at times literally). Keeping the focus of everyone’s energy on the development task at hand means a minimum of non-engineering overhead.

Developing and delivering a technology is the root problem set for team members. It is one engineers are well trained for, skilled at, and interested in. Varying skill levels within a small, contained group are readily adapted to and optimized when working closely with the team on a daily basis.

by Michael Turnlund

Sink or Swim: Know When It's Time to Bail

There are endless survival challenges for newly created businesses. The degree to which a business successfully meets these challenges depends largely on the nature of the organization and the culture that evolves within it. That's to say that while market size, technical quality, and product design are obviously crucial factors, company failures are typically rooted in some form of organizational dysfunction. To help investors recognize signs of trouble before catastrophe strikes, I started working more than a decade ago on the Bell-Mason Diagnostic, a quantitative evaluation method that includes a set of rules for examining a company and comparing it with an "ideal" organization.

Sink or Swim, Know When It's Time to Bail
GORDON BELL, MICROSOFT BAY AREA RESEACH CENTER

A diagnostic to help you measure organizational dysfunction—and take action

There are endless survival challenges for newly created businesses. The degree to which a business successfully meets these challenges depends largely on the nature of the organization and the culture that evolves within it. That’s to say that while market size, technical quality, and product design are obviously crucial factors, company failures are typically rooted in some form of organizational dysfunction. To help investors recognize signs of trouble before catastrophe strikes, I started working more than a decade ago on the Bell-Mason Diagnostic, a quantitative evaluation method that includes a set of rules for examining a company and comparing it with an “ideal” organization.

Although designed specifically for people who invest capital in new ventures, the diagnostic can also be used just as effectively by those whose investments come chiefly in the form of time, energy, and imagination. In fact, anyone contemplating joining a startup—or considering whether to stay with one—can read the diagnostic and answer the questions to determine whether the company they have in mind is in reasonably good health.

by Gordon Bell

Curmudgeon

The Economics of Spam

You know what I hate about spam filtering? Most of what we do today hurts the people who are already being hurt the most. Think about it: Who pays in the spam game? The recipients. That's what's wrong in the first place - the wrong folks pay for this scourge.

The Economics of Spam
Eric Allman, Sendmail

You know what I hate about spam filtering? Most of what we do today hurts the people who are already being hurt the most. Think about it: Who pays in the spam game? The recipients. That’s what’s wrong in the first place—the wrong folks pay for this scourge.

The recipients have to actually store the data, which takes disk space, plus the majority of the I/O bandwidth costs: at least once on the network to receive it, and then at least twice on the disk to keep it (storing and then retrieving the space on disk), not to mention the cost of the disk space itself. You might say that “bandwidth is free” and/or “disk space is free,” and it’s true that they are much cheaper than they were when I was a wee lad (we used to say that disks were shipped full from the factory, given that they never seemed to last long—but then I also remember when having an entire gigabyte of space on one multi-rack system was a really big deal). But bandwidth and disk space have never been free, and when you are a large company or ISP, these things can make a difference. In fact, even if you aren’t a large company, spam can pretty trivially saturate your external bandwidth.

by Eric Allman

Articles

The Sun Never Sits on Distributed Development

More and more software development is being distributed across greater and greater distances. The motives are varied, but one of the most predominant is the effort to keep costs down. As talent is where you find it, why not use it where you find it, rather than spending the money to relocate it to some ostensibly more "central" location? The increasing ubiquity of the Internet is making far-flung talent ever-more accessible.

The Sun Never Sets on Distributed Development
KEN COAR, APACHE SOFTWARE FOUNDATION AND IBM

People around the world can work around the clock on a distributed project, but the real challenge lies in taming the social dynamics.

More and more software development is being distributed across greater and greater distances. The motives are varied, but one of the most predominant is the effort to keep costs down. As talent is where you find it, why not use it where you find it, rather than spending the money to relocate it to some ostensibly more “central” location? The increasing ubiquity of the Internet is making far-flung talent ever-more accessible.

That makes sense as far as it goes—but it’s an approach that potentially has a number of side effects even less tangible than the monetary savings. Large projects with widely dispersed participants have problems that are unknown in projects in which all the people involved work in the same building. If project planning is forward-looking enough to be concerned about potential savings, in a perfect world it certainly should also be aware of the other less tangible costs that will be incurred. Alas, it’s not a perfect world, and so the same issues are encountered over and over again as organizations dip their toes in the distributed pool.

by Ken Coar