Posted by s.hettrick on 28 September 2012 - 10:55am

By Gillian Law, Tech Literate, re-posted with permission from the _connect blog.

Creating software that actually does what the user needs it to do is a perennial challenge. There were some weary sighs of recognition from industry veterans in the recent Technology Strategy Board Multi-disciplinary Software Construction Workshop, as they recognised a topic that has been discussed for decades, but still needs to be addressed in the commercial sphere.

“We’ve been looking at this for 20 years,” said Professor Robin Williams, Director of the Institute for the Study of Science, Technology and Innovation at the University of Edinburgh.

“Edinburgh is actually very good at cross disciplinary work, and we aim for collaboration with social sciences, with business studies, with medicine – there are some difficult issues here, and they demand serious academic consideration.”

But however good the work at Edinburgh may have been, the need for better cross-pollination remains, he says. Today’s developers are tackling the same issues, often seemingly unaware of what has gone before.
The event, run by the Technology Strategy Board and sponsored by the ICT Knowledge Transfer Network, brought together academics, managers of small businesses, software developers and other interested parties to talk about how well-rounded software can be created. With statistics being quoted such as “only 30 per cent of IT staff hires are successful”, it was clear there was a hunger to learn how to get the right people in place.

Four speakers in the morning were followed by an afternoon session working in teams to look at just where the challenges for businesses really lie. This was a high energy workshop with fully engaged participants.

Designing human factors into technology

Louise Downe, Senior Service Designer at Engine Service Design, kicked off the morning’s session, joining by Skype from London. Louise shared her experiences of Service Design to show the role of factors such as trust and confidence in our use of machines and software code.

“I’m interested in how the human can be designed into things, to make things work better,” she said. “I like to think of myself as a doctor, in a way. Clients come to me with symptoms, which they’ve often self-diagnosed, and my role is to work out what the real issues are.”

Downe gave examples of different systems and how they work, or don’t work, depending on the human expectations of what is likely to happen. In public toilets, for example, automatic air fresheners have been a massive market success – but automatically flushing toilets rather less so, because of their unpredictable behaviour. “You need to be able to trust machines to think as we do,” or the relationship isn’t going to work, Downe said. The designers of the toilets hadn’t considered things like people moving unexpectedly, or having differently coloured skin, causing problems that quickly led to a widespread distrust and dislike of the technology.

Likewise, people cannot desire new technology until they can conceive of it – in the classic Henry Ford quote, “If I had asked people what they wanted, they would have said faster horses.”

“We can only expect what we have experienced before,” said Downe. She recently worked with a legal firm looking for a way to store information, but which refused to consider a computerised solution. Because those ‘higher up’ in the firm did not use computers, newer, younger staff chose to emulate them and so refused to use computers too. A paper-based system was the only one they could imagine. It can be very hard to convince people to accept new things when they don’t understand enough about how they will work, she said.

What’s possible

Imogen Casebourne, Director of learning at Brighton-based Epic, followed. Epic designs and develops e-learning solutions specific to its clients’ needs in a range of sectors and subjects - induction, product knowledge, health and safety, systems, compliance, equality and diversity, management and soft skills. Epic successfully runs multi- disciplinary design teams in its software development and shows how it can be done today.

“The people commissioning products from us don’t know what’s possible within their budget, or even what’s possible technically – and they certainly don’t care if it’s Flash-based, or what the limitations of HTML5 are. In fact, they have quite low expectations – people don’t know what’s possible until they see it.”
The ideal scenario is to bring together technical staff who know what can be done with outside people who bring fresh ideas, Casebourne said. Epic has found that former journalists are ideal in coordinating the process, she said. “They’re trained to dig things out, to interview people and to get to the right answers. It’s also useful to bring in someone with a visual background – they’ll have good ideas on how the interaction should work.

“And you have to work with ALL the stakeholders, right from the start, if you don’t want to hit problems half way through,” she said.

The power of design

The design of software is hugely powerful, said the next speaker, Nathalie Nahai. Nahai is a web psychologist and speaker, whose book 'Webs of Influence: The Psychology of Online Persuasion' is due out in October.

“Software is creating the infrastructure for our online realities – when you’re authoring those, that’s a position of great responsibility and power. So it’s not just a case of creating something logical, but something that is intuitive... that understands the wider context of human behaviour.”

Good software will ‘configure’ its user, Nahai said. Watching how children learn to use an iPhone or iPad, and then expect to be able to pinch or move other non-touch screens, it’s clear that Apple’s software is altering the way they interact with the world.

Nahai described how people make decisions, and how so many of what we think of as rational decisions are absolutely not, but made on the spot in snap judgements. The ability to make those instant decisions is vital to human survival in many situations, and to our ability to socialise and communicate with other people –so software has to be designed with that in mind.

“Most of our decisions are made beneath our conscious awareness, so you need to be aware [of how other people think,” she said. The differences in decision-making between themselves and users can trip developers up, Nahai said.

eHealth that makes a difference

Dr Claudia Pagliari, a senior researcher, educator and consultant in Health Informatics and Health Services Research at the University of Edinburgh, completed the morning session with her talk, "From small to large companies: Case studies of interdisciplinary approaches in software design."

Dr Pagliari is very involved in the e- health community and in looking at how networked ICT can be used to support the management and delivery of health services.

“That involves technological, legal, organisational, sociological and policy factors – linking the right people in the right formations is key to getting it right.”

And to date, getting it right has proved difficult. While many great projects have been run, it has yet to be definitively shown that eHealth can either save money or definitively improve the outcome for patients or health staff, Dr Pagliari said.

“It’s a very complex area. It’s very hard to translate pilots into real practice, and there’s little robust evidence of it working well.”

There is a “graveyard” of failed eHealth ICT software that has been developed and abandoned without any proof as to its benefit, Dr Pagliari said.

In one trial, which aimed to reduce the cost of health provision to certain patients by using e-Health systems, the patients greatly appreciated the care they received and the feedback on their health, but their clinicians were concerned that it was too rigid and didn’t take subtle, individual factors into account. And indeed, hospital admissions and drug prescriptions rose rather than declined during the trial.

“That’s not what had been hoped for! But the monitoring product meant that symptoms were spotted faster, that might not have been spotted at all otherwise, and there was then a responsibility to act on them.”
Likewise, a mobile app designed to monitor asthma was very popular with new asthma sufferers, who valued the immediate feedback on their symptoms.

“But again, there was no clinical or economic benefit, compared to the paper based tracking that had been used before,” Dr Pagliari says. An unexpected result was that both groups – the app users and a paper- based control group – ended up with better health results, “because the trial pushed everyone to use the guideline processes in place and follow them well,” she said.

Q&A Session

The following Q&A session was a lively one, with a discussion of health data projects in England and Scotland, and what had gone wrong in many of these. This then led into a conversation on how to hire the right people if you want a truly multi- disciplinary approach to creating your software – how do you find the right people, and recognise them or train them? It was agreed that this has been under discussion for decades, with each new generation trying to learn it from scratch.

“We need a mapping of what’s been done,” said Williams. “And we also need to be aware that each piece of software has a past and a future – we need to think about maintenance and multiple cycles of the same software as well as creating from new – how do you distil user requirements as you go on?”

Working groups

The afternoon saw a shift of gears, as the audience and speakers were mixed up and split into three groups.
The first session saw each group try to find an answer to the multi-disciplinary problem from their perspective– what was stopping multi-disciplinary software design? Three key issues were identified: knowing how to recruit people with the right skills, how to approach people who have the right skills but wouldn’t think of working in the area, and choosing methods that were proportionate to the size of the project in getting to know the user.

An hour later, the teams tried their own hand at a multi-disciplinary software design approach, as each group tried to create a blueprint for a piece of software using the skills of everyone around the table. The three tables worked on:

• A system for the prediction and communication of earthquake activity around the world- this raised issues of culture, communication, knowledge of military and national government warning systems;
• A user interface for a TV for use by a family - with questions about privacy, difficulty in defining the ‘user’ in the context of a family, plus hardware issues and potential smartphone use;
• Software to support those who deliver meals on wheels. This brought up sociological issues and a discussion of the psychological motivations of the users, as well as looking at the perils of hot versus chilled food delivery.

Each group came up with some fascinating, in depth and rather brilliant ideas, given the time restrictions and the limited knowledge available about each of the projects. It quickly became clear just how different each person’s take on the task can be, and how useful the variety of perspectives is in creating a well-thought-through software proposals. These software solutions also had to sit in a mix of cultural appreciation of the user and a change in process around them to achieve successful outcomes.

Follow up

Organisers Sarbjit Bakhshi and Jonathan Mitchener wrapped up by asking what would be useful as a follow up activity. “This has been under discussion for decades, and very little has been done about it,” said Bakhshi. “What can we do to change that?”

There was genuine debate about the conflict between different types of training. Academic and other formal methods of computer science training tend to have a stronger focus on understanding the user and developing robust code, compared to the more ‘hands on’ approach of software developers informal training. Is this simply a matter of lack of training, or are there genuine business concerns – are academic practices impractical in the real world? The reality seems to be a mixture of problems but it is clear that more business engagement by academia will help to frame more appropriate software development practices for real life business solutions.

In terms of Technology Strategy Board support, various ideas were posited - if the issue is a lack of information out there, then communities of interest or special interest groups are a good way to keep people talking, perhaps with a series of case studies showing what people are doing, successfully or otherwise. Many previously funded Technology Strategy Board projects have been multi-disciplinary and may have interesting stories to tell.

If the problem is a lack of training, then engaging the software design community with appropriate training in formal methods may be successful.

If the issue is a lack of confidence in this approach, then TSB funded projects may be the solution.
Some participants felt a demonstrator programme might be too narrow in what it could show – that it may only show the efficacy of one type of software development at one particular size of project in one application area.

The TSB remains very much open to suggestions and would welcome any input. Feel free to post them as comments below, we would be pleased to hear from you.

The Multi-disciplinary Software Construction workshop was held in the Informatics Forum of the University of Edinburgh on September 10, 2012.