letters;to;the;editor
DOI: 10.1145/1743546.1743549
Workflow tools for Distributed teams?

The “Profession of iT” View- point “Orchestrating Coor- dination in Pluralistic Net- works” by Peter J. Denning et al. (Mar. 2010) offered guidance for distributed development teams. As a leader of one such team, I can vouch for the issues it raised.

However, my coordination problems are compounded because email (and related attachments) is today’s de facto medium for business and technical communication. The most up-to-date version of a document is an email attachment that instantly goes out of date when changes are made by any of the team members; project documents include specifications, plans, status reports, assignments, and schedules.

Software developers use distributed source-code control systems to manage changes to code. But these tools don’t translate well to all the documents handled by nondevelop-ers, including managers, marketers, manufacturers, and service and support people. I’d like to know what workflow-management tools Denning et al. would recommend for such an environment.

Ronnie Ward, houston, tX

author’s Response:

Workflow tools are not the issue. Many people simply lack a clear model of coordination. They think coordination is about exchanging messages and that related coordination breakdowns indicate poorly composed, garbled, or lost messages (as in email). Coordination is about making commitments, usually expressed as “speech acts,” or utterances that take action and make the commitments that produce the outcome the parties want. People learning the basics of coordination are well on their way toward successful coordination, even without workflow tools.

We don’t yet know enough about effective practices for pluralistic coordination to be able to design good workflow tools for this environment.

Peter J. Denning, Monterey, CA

time to Debug

George V. Neville-Neil’s “Kode Vicious” Viewpoint “Taking Your Network’s Temperature” (Feb. 2010) was thought-provoking, but two of its conclusions—“putting printf()… throughout your code is a really annoying way to find bugs” and “limiting the files to one megabyte is a good start”— were somewhat misleading.

Timing was one reason Neville-Neil offered for his view that printf() can lead to “erroneous results.” Debugger and printf() both have timing loads. Debug timing depends on hardware support. A watch statement functions like a printf(), and a breakpoint consumes “infinite” time. In both single-threaded and multithreaded environments, a breakpoint stops thread activity. In all cases, debugger statements perturb timing in a way that’s like printf().

We would expect such stimulus added to multithreaded applications would produce different output. Neville-Neil expressed a similar sentiment, saying “Networks are perhaps the most nondeterministic components of any complex computing system.” Both printf() and debuggers exaggerate timing differences, so the qualitative issue resolves to individual preferences, not to timing.

Choosing between a debugger and
a printf() statement depends on the
development stage in which each is to
be used. At an early stage, a debugger
might be better when timing and mes-
saging order are less important than
error detection. Along with functional
integration in the program, a debug-
ger can sometimes reach a point of
diminishing returns. Programmers
shift their attention to finding the first
appearance of an error and the point
in their programs where the error was
generated. Using a debugger tends
to be a trial-and-error process involv-
ing large amounts of programmer
and test-bench time to find that very
point. A printf() statement inserted
at program creation requires no setup
time and little bench time, so is, in this
sense, resource-efficient.

 

George V. Neville-Neil’s Viewpoint (Feb. 2010) said students are rarely taught to use tools to analyze networking problems. For example, he mentioned Wireshark and tcpdump, but only in a cursory way, even though these tools are part of many contemporary university courses on networking.

Sniffers (such as Wireshark and Ethereal) for analyzing network protocols have been covered at Fairleigh Dickinson University for at least the past 10 years. Widely used tools for network analysis and vulnerability assessment (such as nmap, nessus, Snort, and ettercap) are available through Fedora and nUbuntu Linux