Learning a craft

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.

Why should I be interested in 3D printing?

I feel like I’ve arrived late to the party. I’d seen David Flanders and others working with 3D printers at Dev8D but I was thinking about other things at the time and never appreciated how significant and wonderful this new technology is and could be. If you’re wondering what 3D printing is, or just don’t get it, watch this and read the articles below. I’m hoping we can get a group together in Lincoln to start making stuff and more printers for others. I know there is interest among some staff and students here and it shouldn’t take much to bring together an informal group interested in exploring the different educational uses of 3D printers (as well as have a lot of fun).

Economist: More than just digital quilting

BBC: 3D Printing offers ability to print physical objects

Ben O’Steen: Making the physical from the digital

Two weeks with a Kindle 3

I have a Kindle 3 (wifi only). Here’s what I think about it after two weeks. I should say that I have absolutely no interest in reading eBooks bought from Amazon on it. What interests me is the ability to read newspapers and academic articles on it.

+ Size, weight and general form are good. Feels nice to hold. I also have the leather case for it, but it doubles the weight and is awkward to hold so I only use it when the Kindle is shoved into my bag.

+ The screen is excellent for reading text in the .mobi and native amazon format. I appreciate the ability to change the font size more than I imagined I would and have found myself wishing that I could change the font size on print books now. The screen appears sharper the more light that is shining on it (i.e. daylight) but is unreadable in poor light/darkness (much like a book).

– Despite the screen being the main strength of the Kindle, looking at a grey scale screen still feels like a distinct step backwards. I’m reminded of using my mid-90s laptop. Page turns/screen refreshes are about as fast as turning a page in a print book, which sounds satisfactory but the experience is all wrong. Page turns are clearly visible screen refreshes/flashes.

– The speed of the device feels retrograde. My touch screen phone feels faster despite having roughly the same 500MHz processor speed.

+ Having said that, from an engineering point of view, the device is apparently a thing of beauty. I can appreciate that.

– The screen is poor for reading A4 sized PDF files. It’s just not big enough and the font on a full page view is too small. On landscape mode, it is better but requires lots of button pressing to scroll through the text and is generally not worth the bother because…

+ You can email .doc and .pdf files (and other text formats) to your @kindle.com or @free.kindle.com email address and Amazon will immediately send you a nicely formatted conversion of the PDF to your device.

+ Feedbooks is a nice way to get out of copyright (i.e. classics) books on the Kindle for free.

– All content is homogenized to become ‘Kindle Content’. Newspapers, books, articles, whatever they originally might have looked like, become the same standardised text on the screen, surrounded by a dull graphite border. I tried to tell myself that it strips away the fluff to reveal the true essence of the book/newspaper/article, but I find the experience of reading otherwise creatively designed content (i.e. a newspaper) on the Kindle quite dispiriting. Even images become washed out and gray. Thankfully, for academic papers, it doesn’t matter so much because they tend to include little more than text in the first place.

+ The battery life is excellent. Over a week with wifi turned on all the time. Apparently a month if turned off, but that’s not how I use it.

– The 3.0 software was very unstable and the device froze regularly. However…

+ The 3.0.1 software upgrade fixes any software issues I experienced.

-/+ The browser is OK. Mobile sites are bearable. I would usually choose using my touch screen phone to browse the web over the Kindle. Web browsing on a slow device with a black and white screen isn’t much fun. However, the ‘Article Mode’ option, which is based on the same idea as Readability, is a nice touch and makes reading a long article a pleasure. Better than using my phone or my laptop or PC. I was already in the habit of saving long print view versions of articles on the web to PDF for reading and now I can email them to my Kindle to read or browse to the web page on the Kindle itself.

-/+ The keyboard is OK. I wish there were keys for numbers. Initially I found the keyboard awkward and navigation around the device and content, a hassle. I’ve got used to it and it’s beginning to make sense to me now. It’s no match for touch screen navigation on the iPhone or Android phones though. The keyboard buttons make a noise so it’s irritating if you’re in a quiet room (i.e. reading in bed with your partner).

– It’s linked to my Amazon account and so it’s yet another device I have to password protect.  I hate the fact that I have to login to the device just to read something.

– The annotation and sharing features are very basic. You can make notes on selected text using the fiddly keyboard but it’s no match whatsoever for the convenience of scribbling in the margins with a pencil. Sharing to Twitter simply tweets a note and link to some selected text on an Amazon web page. I would much prefer a ‘share by email’ feature, like I have on my phone, so I could send myself or others, annotated text by email.

– I wish I had the 3G version. There are times when logging into wifi or having no wifi at all is a minor inconvenience. I thought I’d be able to tether it to my phone but the Kindle wifi won’t work with enterprise/P2P wifi networks. Given the cost, I would trade the leather case for the addition of 3G.

+ Calibre is a fantastic bit of open source software for creating newspapers and delivering them to your device. I have it set up so that my laptop at home wakes at 6am, opens Calibre, downloads three newspapers and sends them to my Kindle ready for when I wake up at 6.30ish. The papers are nicely formatted, with images, and easy to read on the way to work. This somewhat makes up for the complaint about homogenized content I mentioned above. You can pay for Amazon to deliver newspapers to you, too, but by most accounts I’ve seen, they are poorly presented and expensive compared to the print editions. Why bother when Calibre does it for you (and much more)?

– I haven’t used the text-to-speech feature yet. The music player on it is very basic. It’s like using an iPod Shuffle. Stop, start, forward, backwards.

– Already having a smart phone, iPod Touch, home laptop, work laptop and work desktop, the Kindle is an improvement in some areas (straight forward reading of natively formatted text), but is yet another device to throw in my bag. I was sat at a conference recently with my phone, laptop and Kindle all at hand, feeling like a bit of an idiot.

Anytime Anywhere Computing

Together with the ITC Department, we’ve recently begun a feasibility study which looks at related areas of the university’s ITC provision. It brings together three, originally separate proposals to look at upgrading our wireless infrastructure, provide a more flexible desktop experience through virtualisation and improve our understanding of and support for Netbooks and Mobile Internet Devices. It’s good to be working so closely with our ITC Department. So often I hear people at other institutions complain about their ITC departments being ‘brick walls’ and showing no flexibility, but fortunately I can’t say that about my experience at the University of Lincoln.

The Head of ITC sent me a link to this video today. It’s a good example of why our study is both necessary and worthwhile.

Related to this, Tony Hirst recently bookmarked this ITC syllabus for 13-14 year olds recently, which, together with the video, provides a clear indication of what’s happening in schools.

We’re working closely with the Student Council and Academics and intend to survey them on the issues raised by the study early in the new year.  We’ve started talking to vendors of desktop and application virtualisation ‘solutions’, too (the virtualisation of our server infrastructure is almost complete). We’re also lining up some visits to other institutions that have experience in these areas.

If you or your school, your FE or HE insititution has seriously considered or implemented desktop and/or application virtualisation, a full service wireless infrastructure (i.e. it matches the services on your wired network) and support Linux and XP-based Netbooks and other mobile devices, please do get in touch or leave a comment below.

Life on a stick

Last week, I installed the latest Fedora (Red Hat) Linux operating system on a 2GB USB stick. The installation instructions were clear and, using a fast USB stick and PC, runs very well. There’s a nice Windows application that installs Fedora with just a few clicks. I use Ubuntu Linux at home and this was a nice way to try out Fedora and also carry around an entire Operating System with my preferred applications for use whenever I have access to a computer.

I’ve also run PortableApps from a USB stick. This allows me to run applications I use at home, such as Firefox and Pidgin, which are not available on the corporate desktop. The applications run isolated on the USB stick and all settings and cached data is preserved and taken away when you unplug it. The applications run well and look and feel like an application installed on the PC. Only certain applications have been ‘ported’ to Portableapps, but there’s a good selection.

I mention these two experiences because they’re examples of how individuals can continue to personalise their learning or working environments in situations where the computing environment on offer is necessarily restricted for security or support reasons. As software is increasingly running on the web, accessible from any browser, and as we continue to use computers in all aspects of life, whether at home, on the move or at work, there’s an expectation that our personal choices of preferred web browser, preferred IM client, our bookmarks, settings, saved passwords, etc. should continue to be available to us both inside and outside of institutions. JISC’s ‘In Their Own Words‘ report confirms this and apparently some employers are also acknowledging it by allowing staff to purchase their own PC equipment. It says a lot about our relationships with computer hardware and software. Not all technology has this effect on us. I’m still happy to use the work provided fridge and toaster although if I were using them constantly throughout the day, I may begin to object…

Do you wish your personalised computing environment was available to you whenever you turned on a PC?