Seeking the Source: Difference between revisions
No edit summary |
No edit summary |
||
(8 intermediate revisions by 2 users not shown) | |||
Line 4: | Line 4: | ||
* [[Dourish, Paul | Paul Dourish]] | * [[Dourish, Paul | Paul Dourish]] | ||
== Short | == Short Description == | ||
In distributed software development, | In distributed software development, the structure of the software system itself can create dependencies between software elements, while the structure of the development process can create dependencies between software developers. The paper uncovers the structures of software projects and the ways in which development processes are inscribed into software artifacts. With open source communities as an example, a range of organizational processes and arrangements are uncovered in software repositories. | ||
{{Quotation|Software development, then, is a particularly fruitful domain in which to study the relationship between technological artifacts and the social structures that shape them.| [De Souza et al., 2005]}} | |||
== | == Figures == | ||
The following images show specific visualizations by the "Augur" software. | |||
=== Augur Overview === | |||
<br/>[[Image:sts01_overview.png|center|780px]]<br/> | |||
This image shows the overview screen of the Augur software. You can see the different visualisations. As an example the big top part of the image, that shows a representation of source code (lines of code are represented by a line of pixels of certain length). The different colors show, when a part of the source code was last edited. | |||
== | === Network structures === | ||
<br>[[Image:sts02_participation.png|center|780px]]<br/> | |||
This image visualizes different types of networking:<br/> | |||
In a) you can see that the source code of the "surrounding" developers is only called by the code of the author in center. That shows a very centralized network. The author in the center represents the system's architect, who calls the code of other developers. In b) there's a little different situation. A tight network of few authors builds the core of the system, which calls methodes from a few other authors. Finally c) represents a mixture of a) and b). You can't find a defined system core, but a more or less tight network of seven developers. You can also see a periphery of four other developers. Their code just interact with the "core network" but not with each other's. | |||
=== Shifting === | |||
<br>[[Image:sts03_shifting1.png|center|780px]]<br/> | |||
Here you can see developer's code in the software project shifting from a peripheral to a central role. In a) the developer only gabs code of the remaining software (i.e. his code is an interface), where in b) other parts of the software also use his code (i.e. they're implementing the interface). In this example you can see very good, how methodes get stronger integrated into the software. | |||
=== Authorship === | |||
<br>[[Image:sts04_authorship.png|center|780px]]<br/> | |||
In a) (left) you can see a software project relied on a few authors. Open source projects allow developers to join the development team of the software and make changes of the source code. If a new author "overtakes" parts of another author's code by e.g. changing it more often than the original author. So in a) (right) you can see that after some time, a few more developers are involved in the development and they overtake other author's code. In b) you see an example that shows this process vice versa. | |||
=== Stability === | |||
<br><center>[[Image:sts05_stability1.png|300px]] [[Image:sts05_stability2.png|300px]]</center><br/> | |||
"These graphs show, how the structure of the source code (...) is being uset to structure the activities of the developers." [De Souza et al., 2005] In 6/a) you see a implemented module by a certain author. In 7/a) you see, that over some time, nothing has changed. The author is still the main developer of this module. Otherwise, the implemented module in 6/b) was distributet to a certain number of other developers after some time (7/b). | |||
== Suitable for which data types == | == Suitable for which data types == | ||
This visualization method is most suitable for source code. Properties of the software system and the source code itself are mapped to color and other features of a graphical display. Dependencies between methods (e.g. method A calls method B) and other parts of the source code are visualized. Also relationships between programmers can be graphically displayed. With this method it is easy to understand how different programmers are involved in the code production process and how their methods towards or away from the system's core. Even code ownerships can be tracked. | |||
== Evaluation == | == Evaluation == | ||
{{Quotation|In our informal evaluations, developers involved in distributed software development projects relied upon both the activity information and the structure information in coordination to develop a holistic view of software development activity.| [De Souza et al., 2005]}} | |||
== References == | == References == |
Latest revision as of 00:05, 9 May 2008
Authors
Short Description
In distributed software development, the structure of the software system itself can create dependencies between software elements, while the structure of the development process can create dependencies between software developers. The paper uncovers the structures of software projects and the ways in which development processes are inscribed into software artifacts. With open source communities as an example, a range of organizational processes and arrangements are uncovered in software repositories.
Figures
The following images show specific visualizations by the "Augur" software.
Augur Overview
This image shows the overview screen of the Augur software. You can see the different visualisations. As an example the big top part of the image, that shows a representation of source code (lines of code are represented by a line of pixels of certain length). The different colors show, when a part of the source code was last edited.
Network structures
This image visualizes different types of networking:
In a) you can see that the source code of the "surrounding" developers is only called by the code of the author in center. That shows a very centralized network. The author in the center represents the system's architect, who calls the code of other developers. In b) there's a little different situation. A tight network of few authors builds the core of the system, which calls methodes from a few other authors. Finally c) represents a mixture of a) and b). You can't find a defined system core, but a more or less tight network of seven developers. You can also see a periphery of four other developers. Their code just interact with the "core network" but not with each other's.
Shifting
Here you can see developer's code in the software project shifting from a peripheral to a central role. In a) the developer only gabs code of the remaining software (i.e. his code is an interface), where in b) other parts of the software also use his code (i.e. they're implementing the interface). In this example you can see very good, how methodes get stronger integrated into the software.
Authorship
In a) (left) you can see a software project relied on a few authors. Open source projects allow developers to join the development team of the software and make changes of the source code. If a new author "overtakes" parts of another author's code by e.g. changing it more often than the original author. So in a) (right) you can see that after some time, a few more developers are involved in the development and they overtake other author's code. In b) you see an example that shows this process vice versa.
Stability
"These graphs show, how the structure of the source code (...) is being uset to structure the activities of the developers." [De Souza et al., 2005] In 6/a) you see a implemented module by a certain author. In 7/a) you see, that over some time, nothing has changed. The author is still the main developer of this module. Otherwise, the implemented module in 6/b) was distributet to a certain number of other developers after some time (7/b).
Suitable for which data types
This visualization method is most suitable for source code. Properties of the software system and the source code itself are mapped to color and other features of a graphical display. Dependencies between methods (e.g. method A calls method B) and other parts of the source code are visualized. Also relationships between programmers can be graphically displayed. With this method it is easy to understand how different programmers are involved in the code production process and how their methods towards or away from the system's core. Even code ownerships can be tracked.
Evaluation
References
- Seeking the source on ACM]
- Adler, P. (2003). Practice and Process: The socialization of software development. Unpublished manuscript, University of Southern California.
- Bannon, L. & Bøødker, S. 1999. Constructing Common Information Spaces. Proceedings of European Conf. Computer-Supported Cooperative Work ECSCW97, 81--96.
- Bowers, J. 1992. The Politics of Formalism. In Lea (ed), Contexts of Computer-Mediated Communication, 231--261. Harvester Wheatsheaf.
- Geoffery C. Bowker , Susan Leigh Star, Sorting things out: classification and its consequences, MIT Press, Cambridge, MA, 2000
- Brooks, R. 1983. Towards a Theory of the Comprehension of Computer Programs. Intl. Jnl. Man-Machine Studies, 18, 543--554.
- Callon, M. 1986. Some elements of a sociology of translation: Domestication of the scallops and fishermen of St. Brieuc Bay. In Law (ed.), Power, Action and Belief: a new sociology of knowledge?, 196--233. London: Routledge.
- Callon, M. 1986. The Sociology of an Actor-Network: The case of the electric vehicle. In Callon, Law, and Rip, (eds.), Mapping the Dynamics of Science and Technology, 19--34. London: Macmillan.
- Callon, M. 1991. Techno-Economic Networks and Irreversability. In Law (ed.), A Sociology of Monsters: Essays on Power, Technology and Domination, 132--161.
- Conway, M. E. (1968). "How Do Committees invent?" Datamation 14(4): 28--31.
- Crowston, K. and Howison, J. 2004. The Social Structure of Free and Open Source Software. First Monday, 10(2), 2005.
- S. P. Davies, The nature and development of programming plans, International Journal of Man-Machine Studies, v.32 n.4, p.461-481, April 1990
- Cleidson R. B. de Souza , David Redmiles , Paul Dourish, "Breaking the code", moving between private and public work in collaborative software development, Proceedings of the 2003 international ACM SIGGROUP conference on Supporting group work, November 09-12, 2003, Sanibel Island, Florida, USA
- Cleidson R. B. de Souza , David Redmiles , Li-Te Cheng , David Millen , John Patterson, Sometimes you need to see through walls: a field study of application programming interfaces, Proceedings of the 2004 ACM conference on Computer supported cooperative work, November 06-10, 2004, Chicago, Illinois, USA
- Ducheneaut, N. "The reproduction of Open Source software programming communities." Unpublished Ph.D. thesis, U.C. Berkeley.
- Stephen G. Eick , Joseph L. Steffen , Eric E. Sumner, Jr., Seesoft-A Tool for Visualizing Line Oriented Software Statistics, IEEE Transactions on Software Engineering, v.18 n.11, p.957-968, November 1992
- Jon Froehlich , Paul Dourish, Unifying Artifacts and Activities in a Visual Tool for Distributed Software Development Teams, Proceedings of the 26th International Conference on Software Engineering, p.387-396, May 23-28, 2004
- Fujimura, J. 1987. Constructing "Do-Able" Problems in Cancer Research: Articulating Alignment. Social Studies of Science, 17(2), 257--293.
- Fujimura, J. 1997. The Molecular Biological Bandwagon in Cancer Research. In Strauss and Corbin (eds), Grounded Theory in Practice, 131--145.
- Rebecca E. Grinter, Using a configuration management tool to coordinate software development, Proceedings of conference on Organizational computing systems, p.168-177, August 13-16, 1995, Milpitas, California, United States
- Rebecca E. Grinter, Recomposition: putting it all back together again, Proceedings of the 1998 ACM conference on Computer supported cooperative work, p.393-402, November 14-18, 1998, Seattle, Washington, United States
- James D. Herbsleb , Rebecca E. Grinter, Splitting the organization and integrating the code: Conway's law revisited, Proceedings of the 21st international conference on Software engineering, p.85-95, May 16-22, 1999, Los Angeles, California, United States
- James D. Herbsleb , Audris Mockus , Thomas A. Finholt , Rebecca E. Grinter, Distance, dependencies, and delay in a global collaboration, Proceedings of the 2000 ACM conference on Computer supported cooperative work, p.319-328, December 2000, Philadelphia, Pennsylvania, United States
- Latour, B. 1994. Where are the missing masses? The sociology of a few mundane artifacts. In Bijker and Law (eds.), Shaping Technology / Building Society: Studies in Sociotechnical Change, 225--258. Cambridge, MA: MIT Press.
- Latour, B. and Woolgar, S. 1979. Laboratory Life: The Social Construction of Scientific Facts. Beverly Hills, CA: Sage.
- Lynch, M. 1985. Discipline and the Material Form of Images: An Analysis of Scientific Visibility. Social Studies of Science, 15(1), 37--66.
- Lynch, M. 1988. The Externalized Retina: Selection and Mathematization in the Visual Documentation of Objects in the Life Sciences. In Lynch and Woolgar (eds), Representation in Scientific Practice. Cambridge, MA: MIT Press.
- Audris Mockus , Roy T. Fielding , James Herbsleb, A case study of open source software development: the Apache server, Proceedings of the 22nd international conference on Software engineering, p.263-272, June 04-11, 2000, Limerick, Ireland
- O'Mahoney, S. and Ferraro, F. 2004. Managing the Boundary of an 'Open' Project. Harvard NOM Working paper No. 03-60. Cambridge, MA: Harvard Business School.
- D. L. Parnas, On the criteria to be used in decomposing systems into modules, Communications of the ACM, v.15 n.12, p.1053-1058, Dec. 1972
- Schmidt, K. and Bannon, L. 1992. Taking CSCW Seriously: Supporting Articulation Work. Computer-Supported Cooperative Work, 1(1-2), 7--40.
- Kjeld Schmidt , Ina Wagner, Ordering Systems: Coordinative Practices and Artifacts in Architectural Design and Planning, Computer Supported Cooperative Work, v.13 n.5-6, p.349-408, December 2004
- Sharrock, W. and Button, G. 1997. Engineering Investigations: Practical Sociological Reasoning in the Work of Engineers. In Bowker, Star, Turner, and Gasser (eds), Social Science, Technical Systems, and Cooperative Work: Beyond the Great Divide, 79--104. Mahwah, NJ: Lawrence Erlbaum.
- Susan Leigh Star , Karen Ruhleder, Steps towards an ecology of infrastructure: complex problems in design and access for large-scale collaborative systems, Proceedings of the 1994 ACM conference on Computer supported cooperative work, p.253-264, October 22-26, 1994, Chapel Hill, North Carolina, United States
- Lucy A. Suchman, Office procedure as practical action: models of work and system design, ACM Transactions on Information Systems (TOIS), v.1 n.4, p.320-328, Oct. 1983
- David Wagner , Drew Dean, Intrusion Detection via Static Analysis, Proceedings of the 2001 IEEE Symposium on Security and Privacy, p.156, May 14-16, 2001
- Joel West , Siobhan O'Mahony, Contrasting Community Building in Sponsored and Community Founded Open Source Projects, Proceedings of the Proceedings of the 38th Annual Hawaii International Conference on System Sciences (HICSS'05) - Track 7, p.196.3, January 03-06, 2005