Yay! Three Lazy Geeks shortlisted for dev8D prize

We're in the top five, whoop!

The reviewers said, "Really comprehensive treatment of the problem and associated issues. Worth pursuing I think… As a solution this is a good idea and was produced by genuine collaboration at the Dev8D event."

So a short but happy developer post from me. The whole experience was lots of fun, and it would never have worked without Ian Ibbotson and Pete Sefton. I think the thing that I like most about it is that it not only re-uses existing tools, it fits with how people already work. It's not "this application will change your life, but first you have to change your life". I know that the (mostly junior) academics I've mentioned it to have loved the idea, so it might have real users if it was developed, which would be lovely.

Tim Berners-Lee at TED on 'database hugging' and linked data

This TED talk by Tim Berners-Lee: The next Web of open, linked data is worth watching if you've been 'wondering whatever happened to the semantic web?', or what this 'linked data' is about all.

I've put some notes below – I was transcribing it for myself and thought I might as well share it. It's only a selection of the talk and I haven't tidied it because they're not my words to edit.

Why is linked data important?

Making the world run better by making this data available. If you know about some data in some government department you often find that, these people, they're very tempted to keep it, to hug your database, you don't want to let it go until you've made a beautiful website for it. … Who am I to say "don't make a website…" make a beautiful website, but first, give us the unadulterated data. Give us the raw data now.

You have no idea, the number of excuses people come up with to hang onto their data and not give it to you, even though you've paid for it.

Communicating science over the web… the people who are going to solve those are scientists, they have half-formed ideas in their head, but a lot of the state of knowledge of the human race at the moment is in database, currently not sharing. Alzheimer's scientists … the power of being able ask questions which bridge across different disciplines is really a complete sea-change, it's very, very important. Scientists are totally stymied at the moment, the power of the data that other scientists have collected is locked up, and we need to get it unlocked so we can tackle those huge problems. if I go on like this you'll think [all data from] huge institutions but it's not. [Social networking is data.]

Linked data is about people doing their bit to produce their bit, and it all connecting. That's how linked data works. … You do your bit, everybody else does theirs. You may not have much data yourself, to put on there, but you know to demand it.

It's not just about the number of places where data comes. It's about connecting it together. When you connect it together you get this power… out of it. It'll only really pay off when everybody else has done it. It's called Linked Data, I want you to make it, I want you to demand it.

Sophie Germain, a tech heroine

When I first heard about Ada Lovelace Day, I started thinking about who I'd write about. I figured the usual suspects like Grace Hopper were out, but that left the field wide open – there are so many cool women around in different fields.

Yet despite all the possibilities in times and fields closer to my own, I've ended up thinking about a woman who who died 178 years ago. Mathematician and physicist Marie-Sophie Germain has been described as "probably the most profoundly intellectual woman that France has ever produced".  I have long-since forgotten my high school maths and physics, but I was drawn to her stubbornness, her tenacity, her sheer need to keep learning. about.com says:

After discovering geometry, Sophie Germain taught herself mathematics, and also Latin and Greek so that she could read the classical mathematics texts. Her parents opposed her study and tried to stop it, so she studied at night. They took away candles and forbid nighttime fires, even taking her clothes away, all so that she could not read at night. Her response: she smuggled candles, she wrapped herself in her bedclothes. She still found ways to study.

She was eventually recognised by the French Academy of Sciences, though her history is full of poignant reminders of the difficulties she faced.  PBS says:

Although she made no further contributions to proving Fermat's Last Theorem, others were to build on her work. She had offered hope that those equations in which n equals a Germain prime could be tackled, however the remaining values of n remained intractable.

After Fermat, Germain embarked on an eventful career as a physicist, a discipline in which she would again excel only to be confronted by the prejudices of the establishment. Her most important contribution to the subject was "Memoir on the Vibrations of Elastic Plates," a brilliantly insightful paper which was to lay the foundations for the modern theory of elasticity.

From a different perspective:

Although it was Germain who first attempted to solve a difficult problem, when others of more training, ability and contact built upon her work, and elasticity became an important scientific topic, she was closed out. Women were simply not taken seriously. (MacTutor History of Mathematics)

I think this is the saddest of all – Britannica says, "[d]uring the 1820s she worked on generalizations of her research but, isolated from the academic community on account of her gender and thus largely unaware of new developments taking place in the theory of elasticity, she made little real progress."

It's sad, not just on a personal level – imagine having that brain, that drive to collaborate and create, and not being taken seriously because of your gender – but can you imagine how much further the field of mathematics or physics might have advanced if she'd been supported and allowed to participate fully in the scientific community?

I couldn't find any images of Sophie Germain that I could clearly re-use, so instead you could go check out the range of faces tagged womensday on the Flickr Commons site, many of whom are scientists or inventors themselves. If I knew more about them I'd look for candidates for Modern Bluestocking.

Ada Lovelace Day at the Science Museum

I'm really excited that we've managed to get some new pages and updated text about Ada Lovelace on the Science Museum website, and particularly that it's in time for Ada Lovelace Day.  On a personal note, I'm thrilled because 'women in technology' has long been an issue close to my heart.  I think role models are important and I don't know if you can get better than the woman often described as "the world’s first computer programmer". 

It's also exciting because it shows that with the right infrastructure, and institutional support, museums can move quickly (ish) and be responsive to current events.  It couldn't have happened without the support of the curatorial and marketing departments.

The Computing gallery in the Science Museum has some great objects – Babbage's Analytical Engine and the Difference Engine built by the Science Museum according to Babbage's original specifications (and half ofBabbage's brain in a jar).  There are also performances by the Ada Lovelace drama character on Tuesday, March 24, so pop in if you're in London.

Speaking of Ada Lovelace Day, I'd better get my ALD09 blog post written tonight!  If you're not sure who to write about I've posted about possible candidates under the label AdaLovelaceDay09.

Get thee to a wiki – the great API challenge in action

Help us work on an informal, lightweight way of devising shared data, API standards for museum and cultural heritage organisations – museum-api.pbwiki.com is open for business.

You could provide examples of APIs you've used or produced, share your experience as a consumer of web services, tell us about your collections.

Commenting on other people's queries and content is an easy way to get started.  I'd particularly love to hear from curators and collections managers – we should be working together to enable greater access to collections.  If you check it out and none of it makes any sense – be brave and say so!  We should be able to explain what we're doing clearly, or we're not doing it right.

Some background: as announced on the nascent museumdev blog, the Science Museum is looking at releasing an API soon – it'll be project-specific to start with, but we're creating it with the intention of using that as an iterative testing and learning process to design an API for wider use. We could re-invent the wheel, but we'd rather make it easy for people to use what they've learnt using other APIs and other museum collections – the easiest way to do that is to work with other museums and developers. The Science Museum's initial public-facing collections API will be used for a 'mashup competition' based on object metadata from our 'cosmos and culture' gallery.

Speaking of museumdev, I started it as somewhere where I could ask questions, point people to discussions, a home for collections of links and stuff in development.  It's also got random technical bits like 'Tip of the Day: saving web.config as Unicode' because I figure I might as well share my mistakes^H^H^H^H^H^H^H^H learning experiences in the hope that someone, somewhere, benefits.

'The 50 Most Important Women in Science'

More inspiration for Ada Lovelace Day 2009 from Discover magazine's 2002 list of The 50 Most Important Women in Science. Not everyone listed is directly involved with technology, but it's worth checking them out anyway, because as the article points out, '[i]f just one of these women had gotten fed up and quit—as many do—the history of science would have been impoverished':

Three percent of tenured professors of physics in this country are women. Nonetheless, a woman physicist stopped light in her lab at Harvard. Another woman runs the linear accelerator at Stanford. A woman discovered the first evidence for dark matter. A woman found the top quark. The list doesn't stop there, but the point is clear.

Three years ago, Discover started a project to look into the question of how women fare in science. We knew there were large numbers of female researchers doing remarkable work, and we asked associate editor Kathy A. Svitil to talk to them. The result of her investigation is a selection of 50 of the most extraordinary women across all the sciences. Their achievements are detailed in the pages that follow.

To read their stories is to understand how important it is that the barriers facing women in science be broken down as quickly and entirely as possible. If just one of these women had gotten fed up and quit—as many do—the history of science would have been impoverished. Even the women who have stuck with it, even those who have succeeded spectacularly, still report that being a woman in this intensely male world is, at best, challenging and, at worst, downright disheartening.

It will take goodwill and hard work to make science a good choice for a woman, but it is an effort at which we cannot afford to fail. The next Einstein or the next Pasteur may be alive right now—and she might be thinking it's not worth the hassle.

An easy candidate for Ada Lovelace Day – Barbara Liskov, winner of the 2008 Turing Award

How cool is she? ACM Turing Award Goes to Creator of Influential Innovations in Computer Software Design

NEW YORK, March 10, 2009 – ACM, the Association for Computing Machinery, has named Barbara Liskov of the Massachusetts Institute of Technology (MIT) the winner of the 2008 ACM A.M. Turing Award.  The award cites Liskov for her foundational innovations to designing and building the pervasive computer system designs that power daily life.  Her achievements in programming language design have made software more reliable and easier to maintain.  They are now the basis of every important programming language since 1975, including Ada, C++, Java, and C#.  The Turing Award, widely considered the "Nobel Prize in Computing," is named for the British mathematician Alan M. Turing.  The award carries a $250,000 prize, with financial support provided by Intel Corporation and Google Inc.

The first woman to be awarded a Ph.D. from a Computer Science department (in 1968 from Stanford University), Liskov revolutionized the programming field with groundbreaking research that underpins virtually every modern computer application for both consumers and businesses. Her contributions have led to fundamental changes in building the computer software programs that form the infrastructure of our information-based society. Her legacy has made software systems more accessible, reliable, and secure 24/7.

Spotting QR tags in the real world

One of the prototypes made for dev8D has been adapted so it can 'splash a big QR code onto the screen' so people can conferences can take a shot of it and click straight through to the URL – no typing.  Super cool!

I'm excited by Semapedia, a project "which uses QR Code nodes to connect Wikipedia articles with their relevant place in physical space". You can browse locations that have been tagged on a map or on Flickr. I get excited by things like this because it makes 'outside the walls of the museum' projects seem much more feasible.

The ZKM (Centre for Art and Media, Karlsruhe) are exploring mobile tagging for their 20th anniversay: "[w]ith this new tag solution, you can communicate with the museum and use it as a platform also outside of opening hours, i.e., not bound to a certain time, and without being physically present in the museum, i.e., not bound to a certain place." The site is in German so it's difficult to work out exactly what you get online. Thanks to Jennifer Trant for the tip-off.

Two notes on QR tags out in the wild – Seb's recent post linked to 'a guerilla art installation at [Melbourne's] Federation Square' which is ace on so many levels.  I love their ethos.

The image is a photo I took today – a band have put up a QR tag outside a London tube station.  It takes you to a page that links to a downloadable track and their iTunes and MySpace pages.

Tragically, I've even started using QR codes in the office – I often use my phone to test sites outside our network, and I've printed out a sheet of QR codes for sites I check often, to save typing in URLs on my phone keyboard.

Agile development presentation, dev8D

These are my very rough notes on Grahame Klyne's talk on Agile Development as JISC's dev8D event in February. Grahame works with bioinformatics and the semantic web at the zoology department of Oxford University. He is interested in how people can make useful things out of semantic web technologies.

Any mistakes are mine, obviously, and any comments or corrections are welcome. (I should warn that they're still rough, even though it's taken me a month to get them online.) My notes in [square brackets] below.

He started by asking people in the room to introduce themselves, which was a nice idea as most people hadn't met.

Agile and their project
Agile seemed to be particularly appropriate for development in a research context, where the final outcomes are necessarily uncertain. [I'm particularly interested in how they managed to build Agile development into the JISC project proposal, as reflected in 'A call for agile museum projects (a lunchtime manifesto)'. Even getting agile working in a university environment seems like an impressive achievement to me, though universities tend to be more up-to-date with development models than museums.]

They had real users, and wanted to apply semantic web technologies to help them do their research.

At the start of the project, all the developers went on week-long training course on agile development, which was really important for the smooth running of the project as they all came out with a common view on how they might go forward. Everyone worked with 'how can we make this work best for us' view of agile development.

Agile – what's it about?
Agile values individuals and interactions over processes and tools. It values responding to change over following a plan – this is particularly interesting when writing proposals for funders like JISC.

From a personal perspective, the key principles became: what we do is (end) user led; spend a lot of time communicating; build on existing working system code (i.e. value code over documentation); develop incrementally. It's not in all the textbooks but they found it's important – they 'retrospect'.

User-led: you need a real user as a starting point. Not sure how to advise someone working on a project without real users [I didn't ask, but why would you be doing a project without a real users?]. It's far easier to elicit requirements from user if you have a working system.

Build and maintain trust in the team. [Important.]

Building on working code: start with something simple that works. Build in small steps – it's easy to say, but the discipline of forcing yourself to take tiny steps is quite hard. The temptation is to cram in a bit more functionality and think you'll sort it out later. When you get used to the discipline of small steps, it gets so much easier to maintain flow of development.

Minimise periods of time when you don't have working system.

Don't sacrifice quality.

Always look for easy ways of implementing what you need to do now. Don't bring in more complex solution because you think you might need it later.

Retrospection – 'the one indispensable practice of agile'? As a team, take time regularly to review and adjust.

More random points: Test-lead development is often assoc with agile development. Think of test cases as specification – it's also a useful mindset for standards development groups. Test cases are particularly useful when working with external code bases or applications – even more so than when working with your own code. [There was quite a bit of discussion about this, I think whether it made sense to you depended on your experiences commissioning or reviewing possible applications for purchase for institutional use. I can think of occasions when it would have been a very useful approach for dealing with vendor oversell – it sounds like a sensible way to test the fit of third-party applications for your situation.]

Keep refactoring separate from the addition of new functionality.

Card planning: for e.g. user stories, tasks. It's a good solution in an environment with very strong characters, it allows everyone to be confident that their input was being noted, which means they don't hijack the session to make sure their points have been heard… the team can then review and decide which are most important in next small block of work.

Outcomes: progress had been steady and continuous rather than meteoric. What seems like a slow pace at the time actually gets you quite far. It produces a sense of continuous progress.

Unexpected architectural choices – had particular view about how web interactions were going to work in the project, e.g. choice between server side or client side JavaScript – he was sceptical, but knew he could change his mind later, could follow one path and change if necessary. But actually resulted in architectural choices that would never have made upfront but which were best for the situation.

Discussion
Never refactor until you have to. Don't make stuff you *might* need, make it when you need it.

A call for agile museum projects (a lunchtime manifesto)

Yet another conversation on twitter about the NMOLP/Creative Spaces project lead to a discussion of the long lead times for digital projects in the cultural heritage sector. I've worked on projects that were specced and goals agreed with funders five years before delivery, and two years before any technical or user-focussed specification or development began, and I wouldn't be surprised if something similar happened with NMOLP.

Five years is obviously a *very* long time in internet time, though it's a blink of an eye for a museum. So how do we work with that institutional reality? We need to figure out agile, adaptable project structures that funders and bid writers can also understand and buy into…

The initial project bid must be written to allow for implementation decisions that take into account the current context, and ideally a major goal of the bid writing process should be finding points where existing infrastructure could be re-used. The first step for any new project should be a proper study of the needs of current and potential users in the context of the stated goals of the project. All schema, infrastructure and interface design decisions should have a link to one or more of those goals. Projects should built around usability goals, not object counts or interface milestones set in stone three years earlier.

Taking institutional parameters into account is of course necessary, but letting them drive the decision making process leads to sub-optimal projects, so projects should have the ability to point out where institutional constraints are a risk for the project. Constraints might be cultural, technical, political or collections-related – we're good at talking about the technical and resourcing constraints, but while we all acknowledge the cultural and political constraints it often happens behind closed doors and usually not in a way that explicitly helps the project succeed.

And since this is my lunchtime dream world, I would like plain old digitisation to be considered sexy without the need to promise funders more infrastructure they can show their grandkids.

We also need to work out project models that will get buy-in from contractors and 3rd party suppliers. As Dan Zambonini said, "Usability goals' sounds like an incredibly difficult thing to quantify' so existing models like Agile/sprint-esque 'user stories' might be easier to manage.

We, as developers, need to create a culture in which 'failing intelligently' is rewarded. I think most of us believe in 'failing faster to succeed sooner', at least to some extent, but we need to think carefully about the discourse around public discussions of project weaknesses or failures if we want this to be a reality. My notes from Clay Shirky's ICA talk earlier this year say that the members of the Invisible College (a society which aimed to 'acquire knowledge through experimental investigation') "went after alchemists for failing to be informative when they were wrong" – " it was ok to be wrong but they wanted them to think about and share what went wrong". They had ideas about how results should be written up and shared for maximum benefit. I think we should too.

I think the MCG and Collections Trust could both have a role to play in advocating more agile models to those who write and fund project bids. Each museum also has a responsibility to make sure projects it puts forward (whether singly or in a partnership) have been reality checked by its own web or digital specialists as well as other consultants, but we should also look to projects and developers (regardless of sector) that have managed to figure out agile project structures that funders and bid writers can also understand and buy into.

So – a blatant call for self-promotion – if you've worked on projects that could provide a good example, written about your dream project structures, know people or projects that'd make a good case study – let me know in the comments.

Thanks also to Mike, Giv and Mike, Daniel Evans (and the MCG plus people who listened to me rant at dev8D in general) for the conversations that triggered this post.


If you liked this post, you may also be interested in Confluence on digital channels; technologists and organisational change? (29 September 2012) and Museums and iterative agility: do your ideas get oxygen? (21 November 2010).