Category: PhD

Learning a craft

Joss Winn / / Education, Hacking, Hardware, Open Source, PhD, Projects, Software, Student as Producer

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).

DSC03598
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’.

Pair programming

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
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
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.

DevXS: Improve, challenge, positively disrupt

Joss Winn / / Conferences, Fun, Hacks, Mashups, Open Source, PhD, Student as Producer
Even student hackers need to rest

I’ve spent the last five months helping to organise and host DevXS, a national student developer conference. The conference on 11-13th November was fully booked and a great success. Over 170 students attended from across the UK, representing 37 universities, as well as a further 20 tutors and developer mentors working in the Higher Education sector.

You can read more about DevXS on the conference blog which was updated throughout the weekend by a superb team of media students. There are lots of videos and presentation slides on the blog as well as pictures and information about the prize winners and their applications.

It was a really exhausting and satisfying experience to be involved in and not only was it the first conference of its kind in the UK but it looks like it will become an annual event hosted by a different university each year and organised by the JISC-funded DevCSI project.

You can read a report about the conference on the DevCSI website. The Guardian also published an article (originally titled ‘Hacking the Academy’) in the run up to the conference, which I wrote with Mike Neary.

http://youtu.be/DO_tlvy0qs8

Aberystwyth hardware hackers
Aberystwyth hardware hackers
Team HTTP Error #418
Team HTTP Error #418
Some brought their desktop rigs
Some brought their desktop rigs
The Aberdeen team raised sponsorship to attend
The Aberdeen team raised sponsorship to attend
The venue
The Engine Shed, where we lived for two days.

 

 

Hacking the Academy

Joss Winn / / Hacks, PhD, Publications, Student as Producer

An article I wrote with Mike Neary for the Guardian was published last week. It relates to my recent note about Hacking as an Academic Practice and is part of a longer journal article that I’m hoping to have finished by the end of the year about the importance of university culture to the history of hacking.

The publication of the article was nicely timed to coincide with DevXS, the national student developer conference we’re hosting next month. Last week there was a surge of registrations and we’re now fully booked. It should be a great event.

Hackers are vital to the university culture of openness and innovation

Have you noticed anything missing from the ongoing phone hacking scandal involving the News of the World? There are no hackers involved. This is the latest example of hacking’s troubled history with the mainstream media, which confuses the “playful cleverness” of expert computer programmers with the malicious meddling of computer crackers and criminal journalists. With this confusion, the rich and fruitful history of the true hackers is diminished and a thriving intellectual culture focused on problem solving, self-directed learning and the free exchange of knowledge is undermined.

Much has been written about hackers and hacking, but rarely is it contextualised as part of the scholarly tradition. Yet careful reading of the history of hacking reveals that it is very much a part of the work and values of universities and that the hacker ethic is shared, in part at least, by most academics working today.

Read more

Speaking in NYC

Joss Winn / / Open Education, PhD, Presentations, Projects, Student as Producer

Mike Neary and I were in New York City from the 11-16th October, speaking about Student as Producer. We held seminars at Adelphi University, Baruch College CUNY and were part of a panel at the Mobility Shifts Conference at The New School. Here is a recording of the CUNY event, where we had the pleasure of sharing the seminar with Jim Groom, someone who’s been an inspiration for my work on the university WordPress platform.

Hacking as an academic practice

Joss Winn / / Hacks, Identity, PhD

Just a note to say that I think those of us working in universities should be defending the terms ‘hack’, ‘hacker‘ and ‘hacking’. Hacking has had some really bad press recently and as a consequence is terribly mis-understood, but is a term that was born out of the work ethic of pioneering academics and a practice that’s still worth defending. The history of EdTech has its roots in hacking culture. Stand up for it! Stand up for the Hackers!*

hacker: n.[originally, someone who makes furniture with an axe]

  1. A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. RFC1392, the Internet Users’ Glossary, usefully amplifies this as: A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.
  2. One who programs enthusiastically (even obsessively) or who enjoys programming rather than just theorizing about programming.
  3. A person capable of appreciating hack value.
  4. A person who is good at programming quickly.
  5. An expert at a particular program, or one who frequently does work using it or on it; as in ‘a Unix hacker’. (Definitions 1 through 5 are correlated, and people who fit them congregate.)
  6. An expert or enthusiast of any kind. One might be an astronomy hacker, for example.
  7. One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations.
  8. [deprecated] A malicious meddler who tries to discover sensitive information by poking around. Hence password hacker, network hacker. The correct term for this sense is cracker.

The term ‘hacker’ also tends to connote membership in the global community defined by the net (see the network. For discussion of some of the basics of this culture, see the How To Become A Hacker FAQ. It also implies that the person described is seen to subscribe to some version of the hacker ethic (see hacker ethic).

It is better to be described as a hacker by others than to describe oneself that way. Hackers consider themselves something of an elite (a meritocracy based on ability), though one to which new members are gladly welcome. There is thus a certain ego satisfaction to be had in identifying yourself as a hacker (but if you claim to be one and are not, you’ll quickly be labeled bogus). See also geek, wannabee.

This term seems to have been first adopted as a badge in the 1960s by the hacker culture surrounding TMRC and the MIT AI Lab. We have a report that it was used in a sense close to this entry’s by teenage radio hams and electronics tinkerers in the mid-1950s.

In addition to the links above, here’s some worthwhile reading if you’re interested:

* Dedicated to Jim Groom, Tony Hirst, Alex Bilbie and Nick Jackson. Fine Hackers working in universities today.

A Pedagogy of Excess: Interventions in the poverty of student life

Joss Winn / / PhD, Publications

Below is an abstract that I’ve just submitted, to be considered for the special issue of Critical Studies in Peer Production. I was drawn to the call for papers for three reasons: 1) One of the co-editors, Johan Soderberg, wrote an excellent book, Hacking Capitalism: the free and open source software movement (it’s expensive to buy but worth it. His PhD thesis is here); 2) One of the ways I frame our new LNCD group, is around peer-production of technology for education by students and staff; 3) I’ve been planning to write this paper anyway but could do with a deadline. It’ll get written before the end of the year, one way or another. There’s just so much happening at the moment, I could do with a deadline.

== //

A Pedagogy of Excess: Interventions in the poverty of student life

Despite the increasing marketisation of higher education, the generous practices of peer production have long been a characteristic of university life, giving rise, for example, to the emergence of the Free Software, Open Access and Open Education movements. These practices point towards a state of abundance that is not simply a Utopian vision but a real possibility of conditions already in existence within higher education where needs and capacities can be brought together (Kay and Mott, 1982). This possibility of abundance is at the heart of a critical political tradition that the University of Lincoln (UK) is engaged with through its institution-wide Student as Producer initiative (http://studentasproducer.lincoln.ac.uk/), articulated through a ‘pedagogy of excess’ (Neary and Hagyard, 2010) where students are more than just students and become producers of their own social world.

The possibility of a state of abundance in university life has been partially recognised by both the State (e.g. Lammy, 2009) and educators (e.g. Weller, 2011). In the world of Web 2.0, universities are being positioned as ‘edgeless’ resource providers through the funding of Open Access institutional repositories and and Open Educational Resources (Winn, 2011a). Student as Producer both challenges and leverages this abundance of open resources by articulating a pedagogy of excess, whereby the student is encouraged and supported in being not just a student-consumer but rather a critical, productive, social individual. In practice, a pedagogy of excess attempts to re-orientate the roles of staff and students against the marketisation of university life, to become producers of a really existing Utopian university and creators of social wealth (Neary and Winn, 2010).

This paper will introduce the unique approach of Student as Producer at the University of Lincoln and the ways in which we are actively supporting the re-establishment of a ‘hacker culture’ within the university where students are invited to share their ideas, mash up university administrative data and build prototypes that improve, challenge and positively disrupt the research, teaching and learning landscapes of further and higher education. In doing so, I will discuss the theoretical and practical articulation of a pedagogy of excess in terms of the peer-production of technology for education (Winn 2011b) as well as highlight the limits of our approach within a capitalist social universe.

379 words.

Kay and Mott (1982) Political Order and the Law of Labour. The Macmillan Press.

Lammy (2009) The Edgeless University.

Neary, Mike and Hagyard, Andy (2010) Pedagogy of Excess: An Alternative Political Economy of Student Life. The Marketisation of Higher Education and the Student as Consumer. Eds. Molesworth, Scullion and Nixon. Routledge.

Neary, Mike and Winn, Joss (2009) The student as producer: reinventing the student experience in higher education. The future of higher education: policy, pedagogy and the student experience. Continuum, London.

Neary, Mike (2010) Student as Producer: A Pedgogy for the Avant-Garde. Learning Exchange,Vol 1, No 1.

Neary, Mike and Winn, Joss (2010) Education Beyond the Property Relation: From Commons to Communism. Presented at the Open Education 2010 Conference, Barcelona, November 2010.

Weller, Martin (2011). A pedagogy of abundance. Spanish Journal of Pedagogy, 249 pp. 223–236.

Winn, Joss (2011a) Open Education: from the freedom of things to the freedom of people. In: Towards teaching in public: reshaping the modern university. Continuum, London. (In Press)

Winn, Joss (2011b) Technology for education: A new group.

Triple Crunch

Joss Winn / / Climate Change, Economics, Education, Energy, PhD

For much of last year, one of the questions I researched in detail was What will Higher Education look like in a 2050 -80% +2c 450ppm world? My research began with a personal interest in Peak Oil and from there led me to look at climate change and the social and economic impacts of these related subjects. The focus of my research was initially an application for a research grant. You can read the application and the judges comments, which were very favourable but ultimately didn’t secure the grant because it was outside the remit of the programme of funding. Oh well. For months after that, I tried to understand the implications of a future where energy production doesn’t meet demand and the impacts of climate change become more apparent and wrote about it regularly under the tag ‘resilient education‘. Ultimately, my research led me to be quite pessimistic about our ability and willingness to deal with the projected problems. If you read my blog posts, you’ll see that there are really deep structural issues that need to be faced, in particular around the relatively recent obsession with economic growth. I say recent, but the underlying logic of capitalism has always been concerned with the accumulation of surplus value in the form of money, something Marx identified in the 19th century, but it’s only in the last 50 years or so that the idea of ‘economic growth’ has been an explicit political priority.

Anyway, the news over the last week or so has reminded me that the government and mainstream media are literally years behind acting on the research available to them. I was encouraged to read that the UK government seems to be acknowledging Peak Oil and is working with an industry group to model the impact on the UK economy if the price of oil rises to $250/barrel in 2014 (it’s currently around $115). This new relationship might have been forged due to the excellent report that the group produced last year, showing the likelihood of an ‘oil crunch’ in the middle of this decade, or it might have been because the International Energy Agency finally admitted that Peak Oil had actually occurred (in terms of crude oil – not total liquid fuels) in 2006. Energy analysts already knew this – you only had to look at the trend in crude oil production to get an idea – but with the IEA now using the term ‘peak oil’, the issue is bound to get more coverage.

Other news in the last week confirms the problems we face with climate change, too. Again, it takes the IEA to speak out before it gets any real coverage, but thankfully they’ve highlighted the the very tight correlation between economic growth (GDP) and rising emissions, saying that “it is becoming extremely challenging to remain below 2 degrees. The prospect is getting bleaker. That is what the numbers say.”

Finally, Larry Elliot, the Economics Editor for the Guardian wrote a column yesterday, which ties everything up together reasonably well. Energy, the economy and emissions are all inextricably linked and point to a ‘triple crunch’ that is yet to fully impact on the UK. I’m pleased to see this kind of reporting in the mainstream media but what’s really frustrating is that it only took me a few months of research to figure this out. The message has been clear for a number of years now and the public discussion is a decade overdue. There is a substantial body of research which I identify in my blog posts, that points to an oil crisis this decade (not what we’re seeing at the moment, but a real crisis where liquid fuel production falls over a number of years), which shows that the -80% emissions target is all but impossible and that when global net energy production falls, so does GDP.

As I’ve said before, this all has significant immediate and long-term social and political implications, including the effects it could have on the provision of higher education. It’s time that a co-ordinated effort was made by the sector to examine these issues in detail, involving academics from across disciplines as well as business continuity managers and VCs. We really do need to start ‘thinking the unthinkable‘…

Technology for education: A new group

Joss Winn / / Education, Fun, Mashups, Open Education, PhD, Projects, Software, Student as Producer, Support, Web

I offer this as one response to my previous post. Much more needs to be done to ‘reverse imagineer’ EdTech, but this will be my practical focus for the foreseeable future and the nexus of where theory is put into practice, where pedagogy meets technología: “The processes and practices of doing things, understanding things and developing knowledge”? (Selwyn 2011, p7)

A new group

In January, I wrote about how I had written a paper for the university about the role of technology in the context of Student as Producer. The paper included a recommendation that a new team be convened to “further the research, development and support of technology” at the university. January feels like a long time ago now, and I wanted to write about what’s been happening since then, because it’s all good 🙂

Following my presentation of the original paper to the Teaching and Learning Committee, I was asked to provide more detail on what the proposed team would do and a justification for the budget I had outlined. Both papers were written on behalf of and with the co-operation of, the Dean of Teaching and Learning, the University Librarian, the Prof. of Education, the Head of ICT and the Vice President of Academic Affairs in the Student Union. The second paper went back to the T&L Committee and, following their approval, then went to the university’s Executive Board in early April.

I began the paper by outlining what the team is for:

The team will consolidate and extend the existing collaborative work taking place between Centre for Educational Research and Development, The Library and ICT Services ((Since writing this, I’ve listed examples of our existing work in a recent blog post. You can add JISCPress and ChemistryFM, this WordPress platform and our e-portfolio system to that list, too.)) and invite staff and students from across the university to join the team. The team will offer incentives to staff and students who wish to contribute to the rapid innovation of appropriate technology for education at the university, through work-experience, research bursaries and internal and external applications for funding. Through our experience of the Fund for Educational Development (FED) and Undergraduate Research Opportunity Scheme (UROS) funds, we know this is an effective method of engaging staff and students in research and development. A core principle of the team will be that students and staff have much to learn from each other and that students as producers can be agents of change in the use of technology for education.

I then went on to argue:

The Student as Producer project is anticipated to take between 3-5 years to fully embed across the university. During this time, significant changes will occur in the technologies we use. In just the last five years, we have seen the rise of web applications such as YouTube, Facebook, Twitter, and Web 2.0 in general. Aside from such applications, networked infrastructure has developed considerably, with access to broadband now widespread and the use of smart phones and netbooks rapidly increasing. For a student at the University of Lincoln in 2011, high-speed networks are now ubiquitous across the city campuses and such networks themselves are now the ‘learning landscape’, in which the university is but one part.

There is a strong argument for shifting away from the idea of ‘educational technology’ to address technology straight on, recognising that any technology can support and enhance the research, teaching and learning process, and that the use of these technologies increasingly lies outside the institution’s control. We would argue that it is not the university’s role to compete with or determine the use of any technology but rather support access to technology in the broadest terms. This can be achieved through incremental improvements to infrastructure (e.g. network capacity and ease of use), supporting staff and students (e.g. training, workshops, courses) and personalising and integrating the services we do provide so that staff and students have a useful and enjoyable experience of technology at the university and understand how it fits within their wider networks. In particular, we should consider whether Blackboard can be better enhanced through mobile applications and the integration of other popular services such as Facebook. It is a key technology for the support of teaching and learning and if extended through the work of the proposed team, could be a platform for innovation. All of this work should be informed by a broad understanding of the social roles of technology and the objective of producing critical, digitally literate staff and students.

I presented a list of risks that I thought would present themselves if we didn’t take this approach:

  1. Poor co-ordination: Poorly co-ordinated investment in technology to support strategic objectives, resulting in competing interests in limited resources.
  2. Disjuncture: Growing disjuncture between student expectations and institutional provision of technology and support.
  3. Inertia: No locus for technological experimentation and innovation.
  4. Unattractive to potential post-graduates and staff: Technological provision compares poorly to other institutions, putting off new staff and post-graduates.
  5. Loss of income stream: Under-investment in ‘seeding’ projects that may attract external income.
  6. Business As Usual: During a period of significant change in Higher Education, our progressive T&L Strategy is hindered by poorly co-ordinated technological development.
  7. Student as Consumer: Technology remains something ‘provided’ by the university, rather than produced and informed by its staff and students.

Finally, I provided more detail about the costs. After taking into account existing budgets available to us and anticipated external research income, the total I asked for was £22K/yr to pay for an additional 12-month Intern position and a contribution to the staff and student bursaries we want to make available.  This was approved.

I was pleased with the outcome as it means that our current work is being recognised as well as the strategic direction we wish to go in. In terms of resourcing, we will have at least one more full-time (Intern) post and hold a £20K annual budget which will be used to provide grants and bursaries to staff and students, pay for hardware and software as needed and pay for participants to go to conferences to discuss their work and learn from the EdTech community at large. This doesn’t include any external income that we hope to generate. The nature of our applications for research grants is unlikely to change other than we hope to have more capacity in the future including both students and academic staff as active contributors to the development, implementation and support of technology for education at the university.

Team? Group? Network? Place?

The core members of the group (i.e. CERD/ICT/Library) met for an afternoon last week to discuss the roadmap for getting everything in place for the new academic year. We began by discussing the remit of the group (as detailed in the two committee papers), which is principally to serve the objectives of Student as Producer, the de facto teaching and learning strategy of the university. We spent a while discussing the nature of the group; that is, whether it was a team, a network, a group or even a place. In the first committee paper I wrote, I described it as “a flexible, cross-departmental team of staff and student peers”, but have since come to refer to it as a ‘group’, as ‘team’ does not reflect the nature of how we intend to work, nor the relationships we hope to build among participants, nor is a ‘team’ inclusive enough. I’d like to think that we’ll develop a network of interested staff and students and even attract interest and collaboration from outside the university, but I think it’s too early to call what we’re doing a network, although we are networked and working on the Net.  We’ve given ourselves a couple of weeks to come up with name but whatever we call it, we agreed that in principle we’d govern the group by consensus among us. Ideally, though not always in practice, the Net can help us create flatter structures of governance, so we’ll try to shape the way we work around this ideal.  My role will be to co-ordinate the work of the group by consensus.

UPDATE: We decided upon LNCD as the name for our group. It’s a recursive acronym: LNCD’s Not a Central Development group.

All participants will be encouraged to write about their work in the context of Student as Producer, building on the progressive pedagogical framework that is being implemented at the university, theorising their work critically and reflexively. We’ll support this approach, too, building a reading list for people wanting to think critically about EdTech and an occasional seminar series where we’ll discuss our ideas critically, reflexively and collegially.

Road map and tools

We will be up and running by the start of the next academic year. Over the summer, we’ve got a timetable of work that we plan to do to ensure we’ve got a clearly defined identity and the tools in place to support the nature of our work. By the end of September, we’ll have a website that offers clear information on what we do, what we’re working on, how to get involved and the ways we can support staff and students at the university. The site will allow you to review all aspects of our projects as well as propose new projects which can be voted up and down according to staff and students’ priority. There will be an application form for you to apply for funding from us and a number of ways for you discuss your ideas on and offline. We’ll be continuing our current provision of staff training, but will be looking to re-develop the sessions into short courses that are useful to both staff and students. The 2009 Higher Education in a Web 2.0 World report recommended that

The time would seem to be right seriously and systematically to begin the process of renegotiating the relationship between tutor and student to bring about a situation where each recognises and values the other’s expertise and capability and works together to capitalise on it. This implies drawing students into the development of approaches to teaching and learning. [Higher Education in a Web 2.0 World, p.9]

This is very much what Student as Producer is aiming to do through embedding research-engaged teaching and learning across the curricula and the approach we plan to take around support and training for the use of technology in teaching and learning. We’ll be working with the Student Union and the Principle Teacher Fellows across the university to identify ways that students and their tutors can be encouraged to support each other and we welcome the input and collaboration of anyone who wishes to adopt and advocate this approach. We’ll be designing some posters, flyers and business cards over the summer so that people around the university know who we are and how to get in touch in time for Fresher’s Week.

For the Geeks, you might be interested to know that we’ve decided upon a set of tools for managing our work online in a distributed environment where most of us work in different parts of the university campuses. We’ll have a dedicated virtual Linux box (as well as our usual development servers) and the main website will be run on WordPress using our own custom CWD theme. We’ll be migrating all of our code to Git Hub very soon and we’ll be using Pivotal Tracker to manage our development tasks in an agile and open way. We’ll be using our existing combination of Get Satisfaction and Zen Desk to manage peer-to-peer user support and bug reports and we’ll also be looking at alternatives such as User Voice and the Open Source Q&A tool to provide a way for you to suggest and vote for project ideas. Notably, through the use of their APIs, most of these tools integrate well, so that we can create tasks in Pivotal Tracker from bug reports made with Zen Desk and associate those tasks with commits on Git Hub. We’ll be using Twitter just as we always do, and we’ll be using Google Groups for longer discussions around each project (as well as regularly meeting face-to-face, of course). For projects that don’t involve writing code (which we certainly welcome), we’ll be looking at tools that assist with resource development and document control, such as digress.it, MediaWiki, Git Hub, Google Docs, EPrints and Jorum, depending on the nature of the project. We won’t be prescriptive with the tools we adopt, using whatever is appropriate, but with an emphasis on those that offer decent APIs, data portability and good usability. Proprietary software lacking APIs and with poor usability (we can all think of a few) won’t get much of a look in. Finally, through RSS and widgets, we’ll be presenting a coherent picture of each project on the main website.

There’s quite a bit to do but we know how to do it.  If you’ve got any suggestions (a name would be useful!), ideas or even want to join us, for the time-being, leave a comment here and we’ll get back to you. Thanks.