In my previous post, I mentioned a small on-going project I have started to collect short interviews with developers working in universities. It is inspired by The Setup and relates to my interest in hacking in the academy. I hope that over time, it will provide a record of the people working in the developer community and add to the recognition of the work we do, how developers learn and how their working environment impacts upon their work and learning. Here’s the initial announcement I made at Dev8D. Please spread the word.
Calling all Developers working in Higher Education!
I’m setting up a site based on http://usesthis.com but focusing on Developers working in HE. It’s part of a research project I’m embarking on to understand how software developers (in universities) learn their craft.
It would be great if you could send me something. It will be published here http://hackingtheuniversity.net/ It shouldn’t take more than about 15 mins to write and about 5 mins to read (although longer is OK). Over time, I hope to compile a rich profile of developers who happen to work in universities.
How you answer is up to you; browse the site and read other people’s contributions. Alternatively, I’d be happy to accept something different, like this: http://why.usesthis.com/ You don’t need to hyperlink to your software and hardware. I will do that, in many cases automagically!
Here are my interview questions. If you don’t feel like writing, I’d happily accept an audio file to transcribe.
=======
Who are you, and what do you do?
foo
Who taught you how to do what you do?
bar
What tools do you use?
foo
Describe your dream working environment.
bar
========
I need a nice image of you, too, at least 500×335 pixels.
During my attendance at Dev8D last week, I used the time to start pulling together some ideas I’ve been knocking around for a few months now. Most of the projects I’ve helped set up or led over the last three years have involved working closely with developers working in higher education and ever since JISCPress, we’ve been growing a culture where student developers, either on bursaries, employed part-time or full-time recent graduates (i.e. their first ‘proper job’) are core contributors to the project. My point here is that through these projects I have been able to observe how young hackers learn their craft and make the transition from a formal education in Computer Science to learning on the job (i.e. apprenticeship).
DevXS http://devxs.org
I use the word ‘craft’ deliberately. I think our work is much more closely aligned with craftsmanship than with engineering but I was unsure how to articulate this until I read Pete McBreen’s Software Craftsmanship. McBreen argues that a focus on craftsmanship is to return to the roots of software development:
Good software developers have always understood that programming is a craft skill. Regardless of the amount of arcane and detailed technical knowledge that a person has, in the end, application development comes down to feel and experience.
McBreen distinguished software craftsmanship from software engineering and computer science, not as their opposites but as a different tradition “that happily coexists with and benefits from science and engineering.” He compares the software craftsman to the blacksmith, both of whom transcend science and engineering and benefit from improvements in their tools, materials and understanding. For McBreen, GNU/Linux is an example of software craftsmanship that thrives due to the dedication, skill and craft of the people who contribute to the development of the operating system.
‘Software engineering’ was born out of a so-called ‘software crisis’, identified at a NATO conference in 1968. It was determined that the way out of that crisis was to apply an engineering approach to large scale state of the art defence projects. Since that time, argues McBreen, “the needs of the US Department of Defence have dominated the conversation about software engineering.”
software engineering is not all that relevant to many projects. Software engineering was created to solve the problems of really large groups working on multiyear projects. Most modern software development, however, is done in relatively small teams.
Not surprisingly, the practise of software craftsmanship is often allied with agile development, which emphasises the human aspects of software development, the creative and variable processes involved in creating software that meets human needs. Both share a concern with quality and both encourage continual reflective critique of one’s work in order to improve the software and oneself. In his book on Crystal Clear, for example, Alistair Cockburn identifies ‘reflective improvement’ and ‘osmotic communication’ as two of the three minimum requirements for a Crystal Clear project. In practice, reflective improvement refers to workshops and end-of-iteration discussion about how the work is going and how it might be improved. Osmotic communication refers to how flows of information between developers should be unobstructed by locked doors, walls and corridors. It’s about sitting developers in the same or adjacent rooms so that they absorb information about the project with as few barriers as possible. Access to information, a safe environment where people can respectfully speak their minds and close collegial working are highly valued. At times, developers will program side-by-side or in pairs at one workstation, so as to review each others’ work. He refers to this as ‘peer code peering’.
Both reflective improvement and osmotic communication can be enhanced by the choice of tools developers use and the feedback they provide to her. Craftsmen in all trades rely on their tools to provide feedback – a joiner’s plane, a responsive power drill, etc. Many craftsmen will make their own tools to improve their responsiveness. Cockburn notes that one of the most important tools developers can use is an automated regression test suite, which allows the team to continuously test their work and provides feedback to each developer about the quality of their code. Feedback from a Continuous Integration (CI) suite of tools can be usefully presented by ‘information radiators’, dashboards which typically provide status information of servers, the number of use cases delivered and the number of tests passed. Although, Cockburn doesn’t use the term, I think that reflective improvement and osmotic communication refer to the ‘learning environment’ that the software craftsman creates so as to improve their understanding of their work and further develop their craft.
References to the importance of learning from others and from one’s work are made throughout McBreen’s book, as well as an entire chapter at the end of the book called ‘Perpetual Learning’. There, he outlines how to create a ‘learning environment’ by building a library of books for developers to read, as well as ensuring that they take time out each week to practice or learn something new. Like Cockburn, he emphasises the importance of workshops and a series of seminars where developers discuss their work. In addition, McBreen suggests that developers are encouraged to attend and present at conferences and write papers about their work as well as take on the role of instructor where they are able to do so. Craftsmen continually undertake self-directed learning, preferring non-proprietary, open source tools that are sustained by a community and made freely available to learn from, but more importantly, software craftsmen learn from each other, with master craftsmen mentoring journeymen and apprentices.
In a more recent book on software craftsmanship, Apprenticeship Patterns, Hoover and Oshineye also devote a chapter to ‘Perpetual Learning‘, offering further practical advice to aspiring software craftsmen. They list the following:
Expand your bandwidth: Read books and articles, engage with your peers via conferences, social media and mailing lists, join user groups, study from open educational materials on the web
Practice, practice, practice: Take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes. i.e. ‘deliberate practice’ They borrow the term ‘code katas’, whereby programming exercises are repeated again and again until they become ingrained in the individual.
Breakable toys: Budget for failure by designing and building toy systems that are similar in toolset, but not in scope to the systems you build at work. i.e. build something personal to you, that you will learn from. Develop your own CMS or game that you can afford to break while learning.
Use the source: Seek out other people’s code and read it. Start with the applications and tools you use every day.
Reflect as you work: Become a reflective practitioner of software development. This involves regular introspection into how you are working.
Record what you learn: Keep a record of your journey in a journal, personal wiki, or blog. A chronological record of the lessons you have learned can provide inspiration to those you mentor, since it makes your journey explicit, but it can also give you a vital resource to draw upon.
Share what you learn: Early in your apprenticeship, develop the habit of regularly sharing the lessons you have learned. i.e. keep a blog, run workshop sessions, be part of a community of learners.
Create feedback loops: Create mechanisms for regularly gathering more or less objective external data about your performance. i.e. automated regression tests, information radiators, exams and certifications, pair programming, and asking your peers what they think.
Learn how you fail: Seek to identify the ways in which you tend to fail and try to resolve those that are worth fixing.
In his book, The Craftsman, Richard Sennett chooses to focus on open source software development as a modern form of craftsmanship (“the skill of making things well”). The value of Sennett’s book is its breadth of scope. While making no reference to McBreen’s earlier book, Sennett situates open source hacking and the development of GNU/Linux within the social and economic history of craftsmanship and our relationship with technology. For Sennett, Linux is a “public craft” and open source hackers are a “community of craftsmen.” In terms of learning this public craft, he compares ancient pottery making with open source hacking and finds that only the speed between problem finding and problem solving differentiates the two. In programming, and especially open source programming, the velocity at which we can learn can be much greater than in traditional, material crafts. Our tools and the open, distributed nature of developer communities enhance our opportunities for learning. ((Sennett’s observations also help us consider software craftsmanship together with learning theories such as cognitive apprenticeship, situated learning, and constructivism.))
In The Nature and Art of Workmanship, David Pye does not make reference to software development but does develop a very useful framework for identifying and understanding craftsmanship, which complements much of what Sennett and McBreen describe. For Pye, craftsmanship is the workmanship of risk; that is, work that is constantly at risk of error in the process of creation. A simple example of this is writing with a pen. In contrast to the workmanship of risk (craftsmanship) is the workmanship of certainty; that is, workmanship where the quality is always pre-determined and is usually found in quantity production, and always in fully automated work. An example of this would be modern printing. The workmanship of certainty is most common in modern, industrial society, but has existed in some form for hundreds, if not thousands of years. All types of workmanship exist somewhere on the axis between risk and certainty and furthermore are subject to varying degrees of regulation or freedom.
Workmanship
What distinguishes the degree of risk or certainty for Pye is the extent to which the workman’s tools regulate his work. Pye argues that a pure form of workmanship of risk is hardly ever seen in any trade; for centuries people have developed tools to help regulate their work in some way (e.g. jigs) and guarantee some degree of certainty in the quality of their work. Regulation of work does not necessarily lead to certainty as some tools such as a lathe can be used in combination with a free hand, producing unique objects that are nevertheless regulated in some respects such as their size but not their form.
A simple way of asking whether it is workmanship of risk or certainty is to ask, “is the result predetermined and unalterable once production begins?”
In the drawing above, I have speculated that software craftsmanship as McBreen describes it, would be called workmanship of risk by Pye, with regulation introduced by tools such as Integrated Development Environments (IDE), Continuous Integration (CI) suites and the general operating system environment the developer is working with. Although regulated, like almost all workmanship of risk, the software craftsman often produces something bespoke to the users’ requirements, iteratively working towards the desired result through the writing and refactoring of code. Agile software development recognises that the result of most software development cannot be predetermined and that projects run best when they remain responsive to the users’ feedback. Software Engineering, on the other hand, aims to eliminate as much of the risk as possible and pre-determine the outcome of the design and programming effort, which both McBreen and Pyritz both identify as a form of Taylorism.
The Institute of Electrical and Electronics Engineers defines software engineering as “the application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software”. Pyritz questions whether the Taylorist model of scientific management is even viable in software development, quoting Humphrey, who asked ‘Why don’t they practice what they preach?’
The general practices of industrial software engineers are poor by almost any measure”. Why? “The educational system does not provide graduates with the practical skills they will later need. . . . Few software organizations are willing or able to provide the remedial training their new engineers need. Today’s software organizations have few if any role models who consistently demonstrate effective work habits and disciplines.
In learning to become software craftsmen we need role models, too. Both McBreen and Sennett emphasise the importance of apprenticeship and slowly learning by doing with others. This is what JISC’s DevCSI offers to the sector, running regular hack days, DevXS and the annual Dev8D conference. This year over 250 developers attended Dev8D to learn from each other.
Learning from each other at Dev8D
While I was at Dev8D, I issued an informal survey asking developers a number of questions about their working environment, how they learn their craft, the tools they use and an assessment of their skills. I shall provide a summary of the responses in another post [UPDATE: here it is], but I am encouraged to do further research in determining how developers (working in tertiary education) learn their craft and how opportunities for learning might be improved.
Another related project I started while at Dev8D was Hacking the University, a simple website intended to collect short interviews with developers working in universities. It is inspired by The Setup and I hope that over time, it will provide a record of the people working in this community and add to the recognition of the work they do, how they learn and how their working environment impacts upon their work and learning.
If you are a developer working in a university, please consider contributing to Hacking the University and telling others about your approach to your craft.
While preparing my ‘Thinking Aloud’ seminar on Academic Commons, I was pleased to see that the Wikipedia entry for Open Educational Resources notes:
What has still not become clear by now to most actors in the OER domain is that there are further links between the OER and the Free / Libre Open Source Software (FLOSS) movements, beyond the principles of “FREE” and “OPEN”. The FLOSS model stands for more than this and, like e.g. Wikipedia, shows how users can become active “resource” creators and how those resources can be re-used and freely maintained. In OER on the other hand a focus is still on the traditional way of resource creation and role distributions. [my emphasis]
As it happens, this is a significant interest of mine and one I touch upon in a forthcoming book chapter I contributed to. We conclude:
The idea of student as producer encourages the development of collaborative relations between student and academic for the production of knowledge. However, if this idea is to connect to the project of refashioning in fundamental ways the nature of the university, then further attention needs to be paid to the framework by which the student as producer contributes towards mass intellectuality. This requires academics and students to do more than simply redesign their curricula, but go further and redesign the organizing principle, (i.e. private property and wage labour), through which academic knowledge is currently being produced. An exemplar alternative organizing principle is already proliferating in universities in the form of open, networked collaborative initiatives which are not intrinsically anti-capital but, fundamentally, ensure the free and creative use of research materials. Initiatives such as Science Commons, Open Knowledge and Open Access, are attempts by academics and others to lever the Internet to ensure that research output is free to use, re-use and distribute without legal, social or technological restriction (www.opendefinition.org). Through these efforts, the organizing principle is being redressed creating a teaching, learning and research environment which promotes the values of openness and creativity, engenders equity among academics and students and thereby offers an opportunity to reconstruct the student as producer and academic as collaborator. In an environment where knowledge is free, the roles of the educator and the institution necessarily change. The educator is no longer a delivery vehicle and the institution becomes a landscape for the production and construction of a mass intellect in commons. ((Neary, M. with Winn, J. (2009) ‘Student as Producer: Reinventing the Undergraduate Curriculum‘ in M. Neary, H. Stevenson, and L. Bell, (eds) (2009) The Future of Higher Education: Policy, Pedagogy and the Student Experience, Continuum, London))
I’d be interested in discussing these ideas with anyone who has similar interests. I don’t doubt I have a lot to learn from others.
Having been part of the open source community for the last eight years, I am utterly convinced there’s a lot to learn from the collaborative and highly productive social and creative processes that allow software developers, documentation writers and application end-users to work together so effectively. Over decades, they have developed tools to aid this process (mailing lists, IRC, revision control, the GPL and other licenses, etc.). Isn’t it time that more of us worked and learned in this way? Creative Commons is our license to do so; the Internet is our means of connecting with others. The tools are mostly available to us and where they are inappropriate for our discpilines, we should modify them. In the FLOSS community, knowledge is free and the community is thriving.
As the Wikipedia OER article states, the transmission of knowledge from teacher to learner is slowly being freed, but the social processes of knowledge production remain largely the same. Students are still largely positioned as consumers of knowledge and the hierarchical relationship between teacher and learner is increasingly contractual rather than personal. There are exceptions, I know, but there are few genuine opportunities for teacher and learner to work together productively, especially on a group scale. Institutions, like my own, are making some efforts to change the ‘Learning Landscape’ but I don’t think it is necessarily an institutional responsiblility. It’s the responsiblity of individuals (especially in an environment so relatively loosely controlled as a university) to work out the social relations and processes of peer production for themselves, looking for support from others when they need it.
How can the model by which the FLOSS community works so productively and openly be translated to every academic discipline and change the way that knowledge is both produced and transmitted? Technology is at this core of this enterprise and I suspect many teachers and learners feel alientated and divided by it.
By the way, here’s my Thinking Aloud presentation.
Grace Agnew, from Rutgers Universities Library, presented over 40 PPT slides on Digital Rights Management. Her book is due to be published later this year. It’s still not clear to me why we need DRM in open access repositories. Surely this conference is an opportunity to promote the benefits of Copyleft. A simple way of managing the rights to academic research, which costs nothing, is to attach a Creative Commons license to the work. It’s what software developers, with the similar GPL license have been doing for 20 years with great reward. Of course, this ignores the issue that for most academics, the IPR ultimately belongs to the University and it’s at this level that the discussion needs to be had. An academic who deposits their work in a repository and chooses to license their work under a Creative Commons license, may be forgetting that they do not own the work in the first place. In practice, academics are usually free to publish their work as they wish, but the explicit application of a Copyleft license is, unfortunately, not a guaranteed right.
Next, Brian Fitzgerald, from QUT Law School, discussed the OAK Law Project. The project looks fascinating and notably links to the Creative Commons initiative in Australia. It’s a shame that Brian didn’t talk about that and its relevance to open access repositories.
Finally, Jenny Brace, from the Version Identification Framework Project, presented the results of their project. By this point, the microphone in the auditorium had stopped working and I couldn’t hear very much, which was a shame, as it’s an important and interesting area of study, something which I’ve had to deal with ever since working in Collections Management at the NFTVA, where the correct ‘versioning’ of TV and Film materials was a constant issue. ‘Version’ means different things to different groups of people.
