"Managers and programmers alike often brush the data away, clinging to the idea that putting two people on one job must double staffing requirements and therefore cannot deliver efficiency."
I am a bit confused about this statement. Earlier, in the article, it was mentioned that, "Solutions produced by the pairs took 60 percent more total time, but dividing the total time by two, they completed the tasks 20 percent faster". So although it doesn't double the staffing altogether, it does increase it by 60 percent? Am I missing something?
posted by Steve Cheung
October 21, 2011 @ 12:47 PM
I appreciated this article as far as it went, and space limitations always require abridgements. Even so, requirements gathering, client organizational culture, and budgeting/scope creep can be extremely important. So I found it interesting that the author chose not to address these factors and their influence on how well different software development approaches work.
By way of examples, compare and contrast the software engineering for Vista, Firefox, a cruise ship, and the next generation stealth fighter. I would expect Vista and Firefox experiences to be similar because they are both large scale projects where clients (consumers) are atomistic, failure is an option, and requirements are refined along the way. I suspect most if not all of the important decisions about the ship will have been made by the time detailed software design begins. (How big is the ship? What subsystems do we need? How many staterooms and work stations will there be? …) The ship investors may be assisted by staffs, but they will not be atomistic, and failure will not be an option - at least not for critical systems like steering and fire detection. I think the stealth fighter will be somewhat similar to the ship, with the major exceptions that the improved sophistication of foreign militaries, changes in the political landscape, and much higher levels of technology risk will result in great scope creep and expense - even just for the fighter's software. The testing process alone will present very different challenges for these projects.
I wouldn't be surprised if the methods that work best for a Vista or Firefox type project are similar, but I would be surprised if Vista/Firefox best practices also work best for the ship or fighter, or if best practices for the ship and fighter were similar to each other.
First figure out what needs to be done and the environment in which it will be done. Then figure out who should do it and the best way to get it done.
posted by Michael Lehr
October 29, 2011 @ 6:00 PM
"Solutions produced by the pairs took 60 percent more total time, but dividing the total time by two, they completed the tasks 20 percent faster."
Huh? If the pairs are two people wouldn't you *multiply* the total time by 2?
posted by Mike Maxwell
November 20, 2011 @ 5:12 PM
I know there are such things as publication deadlines, but it would help if your authors did better research. The basic sentiments expressed in the article are sound and important, but they should know that good science requires more accuracy in terminology. For one thing they should know the difference between a body of knowledge and a standard. SWEBOK is a GUIDE to a body of knowledge - it is hardly a standard. The authors also don't seem to be aware that there is a U.S. software engineering licensing examination in preparation at this time (not to mention that such licensing has been in place for years in Canada, the UK and Australia). They might also want to note that ABET now accredits software engineering programs and there are already about a dozen accredited programs in the US.
posted by Dennis Frailey
December 16, 2011 @ 5:36 PM
JSTOR, the online academic archive, contains complete back issues of American Scientist from 1913 (known then as the Sigma Xi Quarterly) through 2005.
The table of contents for each issue is freely available to all users; those with institutional access can read each complete issue.
View the full collection here.
An early peek at each new issue, with descriptions of feature articles, columns, and more. Every other issue contains links to everything in the latest issue's table of contents.
News of book reviews published in
and around the web, as well as other noteworthy happenings in the world of science books.
To sign up for automatic emails of the
American Scientist Update
issues, create an
, then sign up in the
My AmSci area