The initiative is one of several of the Kuwait Dive Team’s environmental diplomacy techniques. Becca Farnum is working with the Team, as well as other environmental NGOs in the Middle East and North Africa, to inform her PhD on environmental peacebuilding, exploring the role of nature in diplomatic efforts.
The Inner Harbor Water Wheel harnesses the Jones Falls River’s current to turn a wheel that lifts trash and debris from the water. http://baltimorewaterfront.com/healthy-harbor/water-wheel/
Integrating Conflict Prevention and Resilience for Improved Humanitarian Programming in Pakistan
“Conflict analysis allows us to think ahead more strategically about the work we are doing.” Tim Midgley, Saferworld
On August the 1st 2015, just days after the Afghan government and Taliban’s peace talks in Islamabad are postponed, the LPRR head out to Pakistan to meet the in-county team, launch the project and conduct training around the new integrated resilience and conflict prevention training.
How many times do you return from field work or a holiday to find that most of your first day is spent deleting emails that are no longer applicable or were never relevant to begin with? Or, worse, you are asked to address issue ‘x’ but have no history or documentation to explain how ‘x’ became a problem, what solutions have been considered, or even why you are the one to solve it! Asana and Slack can help with that.
What are they?
In a previous post I pointed to some ways that peer programming could be adapted for module development, now I want to turn my attention to developer tools that help programmers to avoid sending email in the first place. In most cases, these are cloud-based tools that try to make up for some of the basic failures of email:
It is just about impossible to collaborate on a long, complex document via email since you have no versioning control and it can become very, very difficult to know which is the latest version.
Only people who participated in the initial exchanges have access to a full discussion history. Anyone joining later either needs to be forwarded the entire history, or they basically have to jump in blind.
A lot of email traffic amounts to “Have you done this?”, “No, not yet, as I thought you were doing it”, “Oh, ok, now I have”… Does all of this actually need an email? What if someone else wants to comment?
Email is not particularly ‘live’ in that you can’t see someone else’s reply while still composing your own.
Email does not categorise easily – sure, you can categorise by sender, header, or keyword, but that’s all on you. Why not ask the sender to apply some ‘tags’ to help you filter out the ‘chat’ from the ‘this information is critical to the success of the project’?
Slack is designed to help keep lines of communication open within teams, but without that generating a flood of emails mixing in everything from cat photos to “Have you seen what ‘y’ have done? We need to get on top of this right away!” The service is a kind of ingenious blend of IRC, Twitter, Email, and SharePoint. Yes, I really did write that sentence sober.
So how does it work? When you join Slack you join one or more ‘teams’ which are the basic ‘unit’ of interaction on Slack. You can join many different teams, but the messages of one team remain private to that team, and to keep you from accidentally posting to the wrong team you have to ‘switch teams’ in order to post content to other teams.
Within each team you can have any number of ‘channels’. So that’s the IRC bit: each channel has a purpose, and this can be everything from ‘deadlines’ to ‘random’ (for the cat photos, naturally). Using the Twitter-familiar hashtags you can categorise your messages/posts into one or more channels. There’s also the ‘@’ sign to draw an item to a team member’s attention, and so on. So that all cuts back on cc’ing and to-ing-and-fro-ing, and more importantly: you’ll never get the entire history included in the reply-to-all.
The final, SharePoint-y bit is what makes Slack into a fully-fledged business app: using service integrations you can automatically consume data published across a variety of services (github, Twitter, blogs, Dropbox, etc.) and route it to a particular channel. So if you want to track a competitor’s press releases you can do that. If you want to share a Dropbox document for collaborative editing you can do that too.
Oh, and there are clients for every major O/S: Mac, Windows, iOS, Android, etc. so you can keep abreast of things whether you’re at your computer or away from your desk.
Asana is much more complex service built around task management: at its most basic it’s a kind of shared checklist. But by organising things into projects, checklists and sub-checklists, and assigning them to individuals or groups, as well as giving them due dates, you can set up some pretty complex flows of dependencies. In fact, the wonderfully-named Instaganntt has even come up with a way to turn your Asana project into that dreaded – but still expected by most RCUKs – waterfall chart.
Again, as far as I’m concerned this is all about reducing or eliminating email: you can set up Asana to only watch certain tasks, to send you a summary of what has changed, alert you to what you have due next week, etc. Or you can tell it to shove off and leave you alone. So there’s a pull, not push option if you really dislike email reminders. Most importantly, you no longer need to ‘chase’ people just to find out the status of a job, you can just see if they’ve marked it as completed or not. You can also categorise tasks, linking them to one or more projects or other tasks, so some quite arcane structures can result.
As you’d expect, you can attach files, comment on tasks, reassign tasks, split them up, merge them, and so forth all within the rich web interface. Like Slack there are service integrations that allow you to add more functionality and to automatically integrate things like bug tracking and such, but I’ve not made use of those. As you’d expect these days there are also mobile versions for iOS and Android – they’re a little more limited as some functionality is missing, but more than good enough for keeping tabs on things while out of the office (or for catching up when you get back if you really do manage to switch off).
Relevance to Teaching & Administration
If you’ve had to use Moodle – the Open Source ‘blackboard’ app – then you’ll know that its 2-way communications functionality is rather poor: it’s fine for blasting the students with a message about exams or a change to the readings, but it’s not exactly encouraging of course-related ‘chat’ as it comes across as rather clunky (you need to navigate through several pages to even get to the messaging functionality for a given module) and very formal.
We’re going to be experimenting with Slack for our new Geocomputation pathway which starts in a week’s time in the hopes that it encourages students to support one another while also giving us a way to spot recurring problems or questions (and to not have to reply multiple times via email to those recurrent problems). By enabling more fluid conversation, and giving us a way to channel communications into appropriate categories, we’re hoping that students will be more open about the challenges they’re facing and will put us in a better place to help them learn to programme (as well as do statistics and spatial analysis!).
Of course, it would get hard on us if the students started to expect replies at 2a.m., but that’s where we hope the more open structure of Slack will come to the rescue: chances are, quite a few of our students will be working late to master Python and submit the requisite code on time, so they can help one another in a way that’s a lot more similar to what they’d encounter in the real world (where Slack is used by a lot of software shops) than what they’ve normally had to deal with in Moodle.
Asana is less obviously relevant for students, and here I’m using mainly for organising our thinking and planning on one of the departmental committees. We’ll see how well that goes, but early indications are pretty positive: no one has complained to me that the site was unusable or nonsensical, and I’m hoping that my colleagues will find it useful to have categorised ‘to do’ lists and a clearer understanding of who is working on what, and what issues are outstanding (e.g. unassigned or unresolved). So, with luck, it will again mean less email, more effective communication, and a higher level of ‘output’
I’m finding both of these tools really helpful for managing both the ‘meta’ part of teaching and also for grant/project management work. If you have other favourite tools for unblocking your inbox then feel free to share!
 There are plenty of other services, of course, but these are the ones I’m familiar with.
I recently wrote up some thoughts on the value of peer programming as a tool for academic use in course planning and administration. The short answer: really useful but, like all things, best used in moderation. Read more at: Peer Programming for … Continue reading →
As we prepare to teach the first year of the GSA pathway, we’ve been experimenting with techniques more commonly used in software development to see if they can help us to deliver quality and integration in our new modules right from the start. This post will explore the logic of Pair Programming.
What is Pair Programming?
In the traditional software development arena applications are designed by a group of experts; they then hand a set of requirements over to a programmer who heads off to their desk to write the code that will meet those requirements. If the requirements are sufficiently well thought-out and extensive then delivering code that meets those requirements means the project is a success.
There’s just one problem: how often has anything complex been sufficiently well thought-out that individuals, working in isolation, have been able to deliver something integrated and feature-complete on the first go? Actually, there’s a second problem: it is also possible to write something that fully meets the requirements, but doesn’t meet the needs of the application or the organisation. While I work away on ‘my’ bit, I miss a major issue that was also hidden from the application’s designers because no one has an eye any longer on the ‘big picture’ of what the application is supposed to actually do.
It’s into this breach that Agile-derived pair programming steps as a way both to keep developers looking at the big picture, and to enable individuals to access the type of practical knowledge that is only formed through long or diverse experience. Sometimes called peer programming (which is a rather nice terminological link to academia), pair programming matches a ‘driver’ who focuses on the tactical aspects of task completion with an ‘observer’ or ‘navigator’ who “continuously and actively observes the driver’s work, watching for defects, thinking of alternatives, looking up resources, and considering strategic implications” (Williams et al., 2000). In other words, the driver has someone looking over their shoulder… but in a constructive way.
Issues in Pair Programming
Can it work? Programmers aren’t known for their tolerance of being supervised or managed during programming tasks, so there are a number of techniques designed to make this a more constructive experience: for instance, the pair switch roles regularly so that each person ‘drives’ for a while and then puts on the strategic thinking hat for a bit. And repeat. The constant role-switching means that both programmers have an opportunity to do both types of thinking, which builds up practical knowledge and also helps to ensure that many more possible approaches to a problem are considered.
So, by pairing old hands with novices pair programming encourages sharing of ‘best practice’ and yields immediate and frequent feedback during development. That said, you don’t ordinarily pair very experienced programmers with complete novices because the knowledge gap is too wide; it’s common to pair novices and intermediates, or intermediates and experts, with the idea being that the more experienced person still remembers having to learn what their ‘junior’ is trying to understand at the same time as it gives them a chance to systematise their own experience through teaching.
Obviously, some level of social aptitude/sensitivity and trust is also going to be important here, but somehow many Agile firms have managed to make it work. Interestingly, developers actually report finding the process quite enjoyable, while businesses report 40% faster turnaround, more efficient code, and fewer defects (ibid.). And it has been noted that pair programming works best on challenging tasks that call for creativity and ‘sophistication’ (Lui and Chan, 2006).
Applications in Academia
These types of benefits are clearly relevant for thinking about teaching and administration in academia where there is often a poor understanding, especially amongst new hires, of the objectives of a particular task, its rationale, and the range of viable solutions. So while none of us involved in the GSA pathway would claim to be experts in either module design or programming, we thought that pairing would be useful for new module development because we could cover each others’ ‘weaknesses’ while also talking out the overall strategy of the modules themselves.
So far, the results are really promising: although two of us had to invest fully 1.5 days working together (and switching offices since no one else can use my Kinesis Contour keyboard) to develop a week-by-week teaching plan that incorporated pre-class readings, in-class concepts, and practical work, I feel that the result is looking much better – more integrated and with an obvious appreciation of what concepts need to be covered in which weeks in order to bring the students to the final assessment – than if we’d tried to each tackle ‘our’ bit independently. We also brought more ideas and resources to bear on how we might teach each concept and came up with what I think are really good ideas for testing student learning.
Personally, I’ve found it so productive that, where remotely practical, I’m thinking of inflicting it on every team taught module I’m involved in. That said, like all things it’s probably best in moderation and may be most valuable during the planning stage, less so during the “I need to create my PowerPoint slides” stage.
So that’s peer programming – or, in this case, peer planning – and we’ll try too post about the other techniques and tools we’ve experimented with over the coming months.
Lui, K.M. and Chan, K.C.C. (2006), ‘Pair Programming productivity: Novice–novice vs. expert–expert’, International Journal of Human-Computer Studies, 64(9):915–925.
Williams, L. and Kessler, R.R. and Cunningham, W. and Jeffries, R. (2000), ‘Strengthening the Case for Pair Programming’, IEEE Software, July/August 2000, pp.19–25.