It design for Amateur Communities Cristian Bogdan Stockholm 2003 Doctoral Dissertation Royal Institute of Technology Department of Numerical Analysis and Computer Science
Toward an approach to self-sustainability based on member personal development
Download 0.67 Mb.
|
- Navigate this page:
- 4.8.1Member development paths
- 4.8.2Aspects of personal development
- 4.8.2.1Challenge diversification and professional tools in ITD
- 4.8.3Approach to self-sustainability
4.8Toward an approach to self-sustainability based on member personal developmentKaramba adds value to people, if we could just make them understand that! Wanted to be a (training interest group) member, too much [information] technology in my life, but then I saw it’s not the same thing, also technology is different The meeting in Stockholm was a big development… Maybe it was I who developed? Members quoted above all refer to personal development while working in ITC. Personal development is seen a possibility for people who do not yet know about software design (Karamba), personal development is considered as a criterion when a choice is made about deciding whether to join a training committee, or a software-related committee, and finally moments of personal development are evoked. Most inspiring for the present discussion are the member opinions that mention implicitly or explicitly other activities than software design and software development as alternative challenges that could be taken. How would people make the choice to join PD-related amateur activities? And, in the interest of self-sustainability, how would they decide to stay, and go on and do more difficult tasks? As it will be argued here, in making that choice, the possibilities of further personal development are considered. This is similar to the findings of Carroll et al. (1995) who also mention the evolution of their ‘amateur’ designers through phases like “informant”, “analyst”, “designer” and “coach”, however, they do not relate member development to self-sustainability. 4.8.1Member development pathsTo take that perspective further, this section will present and comment on three IT Committee member evolutions. In commenting upon them, we will follow aspects of challenge diversity, learning and other forms of personal development. RayEarly 2001: 1st year Computer Science student, joins ITC. Summer 2001: takes contact with Makumba MDD and JSP levels, starts learning Java (knew C++) Autumn 2001: starts implementing Johnny in Makumba in hands-on sessions with the author, then in 2 international meetings in cooperation with other developers. In meetings he works mostly with Business Logic (BL, in Java) and other amateur developers help with JSP Early 2002: being the only member who knows BL, sets up the structure of the Private Area (PA) BL, will be continued by other developers later Spring 2002: elected “Chief Technical Officer” (CTO). Johnny TS is launched. Spring-summer 2002: other members look (via Parade) at Ray doing a part of Johnny BL and get inspiration for doing the PA BL Autumn 2002: starts developing on Makumba internals As with many other members, Ray’s remarkable progress (e.g. from not even knowing Java to starting to develop on a 300-file Java library) is due in large part to his personal talents and knowledge, as different from, or (hopefully) in addition to, the action of the author. He managed to make possible the first Johnny responsible change after four years. Since Johnny supports the most important programme of BEST (Vivaldi) and is the most computing-intensive application, handing Johnny over to a 2nd year student was an important achievement for ITC. One year after starting development on Johnny, Ray became the youngest Makumba trainee developer. Since Makumba is a complex library, mostly students from terminal years (2 persons at the moment), or graduated (2* persons, i.e. author included) use to look at its internals. Ray followed a ‘homogenous’ development path; he was constantly interested in software development and made intense progress in that area, (in ‘Legitimate Peripheral Participation’ terms, advancing from the periphery to the core of the community of practice). He learned hands-on (especially BL) from the author and others learned BL hands-on and by example (on-line via Parade) from him later on. While Ray is a good representative of a ‘linear-homogenous’ learning path, we will now look at other, more varied development paths. Jane1999: 2nd year student in “Environment and aquatic engineering”, joins Minerva management committee 2000: Local BEST group president Autumn 2000: joins a Karamba working group (Roma) Early 2001: joins a Karamba meeting (Stockholm), works at Makumba MDD level Spring 2001: joins a Karamba working group (Copenhagen), works on archive design Spring 2001: elected “Chief information officer” in charge of the new IT Committee made of “development” and “Feature Design Group” Spring 2001-Spring 2002: participates in 5 IT-related meetings as CIO, as well as at 3 management-related meetings Early 2002: Karamba implementation meeting, does Makumba development at JSP level with the help of developers Autumn 2002: Karamba (feature design group) responsible
Frank1993-1998: studies Computer Engineering 1998-2000: graduate student in Processor Design. Has given high-quality feedback to ITC since 1999, especially in connection to the official WWW archive. Spring 2000: elected secretary of the international board, in charge (among other things) of the official archive Spring 2000-Spring 2001: as board member, gets to work closely with various international teams: marketing and webmaster teams Early 2001: participates with other board members in a Karamba meeting. Interest especially in archives and data structures (MDDs). Spring 2001: international Board mandate ends Summer 2001: Joins the IT Committee (ITC) summer meeting, sees himself as ITC member (feature design interest backed by strong IT background) February 2002: Gets a job, which he describes as coordination of IT projects […] as bridge between users […] and the IT-developers Spring 2002, general meeting: responds to a Makumba questionnaire, sees himself as a Makumba developer. He describes his relevant experience as follows: I knew concepts of relational db from my uni[versity] education (Computer Engineer) though I never toyed with one hands-on… so e.g. no experience setting up a new DB. Same for SQL. Knowledge of Java also from uni, was a good fundamental basis but was waning. Spring-summer 2002: takes over from Ray as main Johnny developer. Due to his job, he does software development at night, after work end 2002: still developing on Johnny. Adds the following line to the signature of many of his Johnny-related mails: Johnny.BEST.eu.org - (de)serving 5000 happy users every year! Frank has probably had the most ‘colourful’ evolution from among the setting members. Although a computer engineer, his training and exercise had little to do with the application domain of the BEST IT (web-based database applications). He evolved from ‘power user’ to ‘main developer of a mission-critical application’ via stages like ‘European secretary’ (with intensive activity in all European Board matters, in close cooperation with the President), ‘marketing’, ‘web content author’ and ‘feature designer’. His mail signature shows the importance of audience for amateur work and suggests a reason for his last ‘amateur work choice’, software development, as well as reason for doing amateur work even after ceasing being a student. From one perspective, as a graduate, Frank is a liability to self-sustainability (though he presently shows no sign of wanting to leave the team). However, a different perspective can regard Frank’s enthusiastic continuation after graduation as a positive evaluation of the support for amateur software development. It is also important to note that his taking over of Johnny from Ray was the first hand-over of a BEST software application that did not involve complete re-writing. The takeover was done hands-on (Frank started improving Johnny by himself, and posted questions to Ray when need arose) over several weeks (around 8, but it is difficult to pinpoint the moment when Frank had taken over), and that encourages us to believe that some other member can take over from Frank in a similarly short time. 4.8.2Aspects of personal developmentAs seen with Jane and Frank, members have a continuous interest in diversifying their challenges. Even if he is interested only in development, Ray is also taking diverse challenges that, although being related to a domain, are diverse: BL programming is mostly procedural Java, while Makumba programming needs much more object-oriented skill. Personal development also has an aspect related to professional counterparts of the new challenges taken. If, while addressing a challenge, an amateur will get to use a tool that is used across the professional-amateur spectrum in the area, the sense of personal development is likely to be strengthened (professional tools are not the only alternative, understanding the whole spirit of a profession such as software design is also a case in point). 4.8.2.1Challenge diversification and professional tools in ITDTo get inspiration in our quest to learn more about member personal development in relation to self-sustainability, we can examine the ITD work as it is at the moment. In approximate order of (technical) complexity, here are the tasks that an amateur can choose to take in the developer group
This allows the members to follow a ‘smooth learning path’ like the ideal we encountered in amateur radio. The variety of difficulty levels can help to challenge amateur programmers of different levels of skill, thus the team is more likely to gain new members, and become more self-sustainable. Examining Table 4 and Table 5 we see that, gradually, the researcher has shifted his participation down the above list, letting the amateurs take his place. This suggests a way in which liabilities for self-sustainability such as professionals who will retire anyway, can be gradually guided to tasks requiring more experience but are less frequent in the life of the amateur group. Combining the generic “developer path” with the three specific learning paths, we notice that often challenge diversification takes place in between design and development. The design-development variety could be taken advantage of by a PD practitioner in such a setting. 4.8.3Approach to self-sustainabilityBased on the observations made at various points in this chapter, we can now suggest an approach to self-sustainability of PD practices in amateur settings.
Download 0.67 Mb. Share with your friends:
|