Collaboration: At the Extremities of Extreme
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Deborah Hartmann Preuss on Sep 10, 2009
A Stanford University study published last month in the Proceedings of the National Academy of Sciences, "Cognitive control in media multitaskers", confirms what seems obvious to many: multitasking, often undertaken for efficiency's sake, is definitely counterproductive. This study looked at a well known, but often disregarded, phenomenon in IT: constant, ongoing multitasking. Agile implementors take note: there's good reason to urge each team to work on one product, with one product owner - splitting attention across many different tasks is a less effective way to work.
Wired Magazine notes that, whereas other studies have focused on multitasking’s immediate effects (for example office workers productivity while constantly checking email), this study asked a different question: “What happens to people who are multitasking all the time?” Stanford researchers Clifford Nass, Anthony Wagner and Eyal Ophir surveyed 262 students on their media consumption habits. The 19 students who multitasked the most and 22 who multitasked least then took two computer-based tests, each completed while concentrating only on the task at hand.
Using several standard psychological benchmark tests of focus, the study showed that college students who routinely juggle many flows of information, bouncing from e-mail to web text to video to chat to phone calls, fared significantly worse than their low-multitasking peers. Researchers were particularly surprised that what they called "heavy media multi-taskers" performed worse on a test of task-switching ability, "likely due to reduced ability to filter out interference from the irrelevant task set."
This study again confirms what cognitive scientists have said all along: processing multiple incoming streams of information is considered a challenge for human cognition.
As for what caused the differences — whether people with a predisposition to multitask happen to be mentally disorganized, or if multitasking feeds the condition — “that’s the million dollar question, and we don’t have a million dollar answer,” said Nass.
Wagner next plans to use brain imaging to study the neurology of multitasking, while Ness wants to look at the development of multitasking habits in children.
Transforming Software Delivery: An IBM Rational Case Study
18 agile and lean practices for effective software development governance
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Since the base article is restricted to subscribers, were you able to read the original article. At least one comment in the Wired article link suggests the research is co-relational, not causational. That is, multitasking is not causing the effect noted, but that multitaskers "choose" to do so to focus on what they consider the most important thing deserving of their attention.
It would be good to be able to see the actual research results since the author of the comment considers the Wired source to be "terrible science journalism."
I think the conclusion is obvious and a lot of time management articles have mentioned it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
2 comments
Watch Thread Reply