John Rooksby

Digital Economy Network Meetings

EPSRC and several of the other UK research councils have been funding “Digital Economy“ themed research for two or three years now – the general aim being to “rapidly realise the transformational impact of digital technologies on aspects of community life, cultural experiences, future society, and the economy”.  The Digital Economy theme has four sub-themes 1: Communities and culture, 2: sustainable society, 3: IT as a Utility, and 4: New economic models. 

This week I have attended two EPSRC Digital Economy workshops: one on IT as a Utility, and one on Communities and Culture.  Workshops on the two other sub-themes also took place.   

Each workshop was intended to kick off what EPSRC is calling a “Network+” – There will be four of these, each centered on one of the sub themes.  Each network+ will have about 1.5 million in funding.  They will:

1. Support secondments/placements to/from academia
2. Fund scoping studies (6 months, approx 50k each)
3. Fund international engagement
4. Fund workshops & mobility

So they do more than the standard EPSRC networks.  I think the detail of exactly what they do and how, is currently being worked out by the respective network leads.  The networks will, as far as I understand, be open to anyone who wants to join.  The intention is that funding for scoping exercises and pilots will be competitive and advertised on the EPSRC website. 

The lead of each network+ was chosen by EPSRC in advance of the workshop from a list of applicants.  Following the workshop, the lead has to write a proposal for the network to get funding.  I am told this will be more than just a formality.  I guess the review process will be to assess whether the lead has to put together a credible proposal, not whether such a network is necessary.       

There were about 40 attendees at each workshop.  I think I was the only post-doc, the majority of attendees were lectures and profs.  I met a few people who were involved in knowledge transfer, including someone from the TSB.  I hear the workshops were oversubscribed (particularly the communities workshop) and the organisers have had to be selective.  I don’t know why I was selected - I don’t think they prioritised attendees by status or success - maybe just by enthusiasm.     

At the core of the workshops were brainstorming sessions.  The first session involved having 10-minute one-on-one talks in which we were supposed to come up with a research idea, the second session involved group discussions.  This was fine – I enjoyed talking with people, and the format was very leveling; I got to speak with senior people on equal terms.  

Several things did bother me though:

1. I think the research councils are trying to be inclusive with “Digital Economy” – it just seems to mean anything you want.  There was some vague talk of our needing “grand challenges” - but nothing specific was mentioned.  I wonder if there was ever a vision at the outset of the Digital Economy programme?  There was certainly no programmatic element to the meeting - it was just a collection of “stuff” - anything goes and everything is of equal value.  Maybe I’m silly to expect anything more than this from a brainstorming workshop.
   
2. The sub-themes might be too broad for a network.  At least two things go as “IT as Utility” 1) Cloud/utility computing, and 2) the integration of IT services into peoples lives.  I think these are separate problems – we don’t need to sort out (2) to do (1) – and frankly we’ve been working on (2) in one form or another for decades. As far as “communities and culture” goes, people at least did recognise that it was a broad area.  But no one seemed prepared to question the very need for this network - everyone is happy to start filling in the details of what such a network needs to do. Can networks work if they have no real focus?  I don’t know why these sub-themes exist as they do, but unless EPSRC have been very slow, they were never created in order to be the theme for a network.  Several years later, someone has come along and said we need networks for the sub-themes - did anyone stop to question whether this is a good idea?
   
3. There was no one there from industry or the public sector.  The were two or three people at the workshop involved in knowledge transfer, but beyond this the only problem holders were scientists.  In many contexts I think there is a good argument for academics to be allowed to get on without others nosing in – but I I would have thought in the Digital Economy programme we need to be talking to the people we expect to impact.  How do we know if we are addressing the right problems?  How do we know if the challenges we come up with have already been solved?  The networks do have money for placements and engagement, so again, i was probably expecting too much of a brainstorming workshop.
   

I’m not sure the extent to which any of these are “problems”.  I raised  these issues with some of the academics there and was told that its often good not to be too focused, and its good not to be creating consensus - we need uncertainty and ambiguity in academia if we are going to be innovative.  I had a brief chat with one of the EPSRC representatives.  He told me that it’s fine, if not a good thing that people don’t agree and don’t have a grasp of the area as a whole – the central issue is that EPSRC need to figure out what will happen beyond the Digital Economy Programme.  In two or three years they need to go to BIS with the next big idea.   Bringing people together with a network is not about bringing people together who already have the answers, but generating ideas.  Its also the case that the network leads have to now write coherent proposals - I’m sure they’ll do a good job.

A paper on collaborative design

I’ve written a little paper with Nozomi Ikeya describing some of the ways in which software developers interact with each other as they brainstorm ideas at a whiteboard.  Its online here.

John Rooksby, Nozomi Ikeya, “Collaboration in Formative Design: Working Together at a Whiteboard,” IEEE Software, vol. 29, no. 1, pp. 56-60, Jan./Feb. 2012, doi:10.1109/MS.2011.123

To successfully collaborate in a creative design session, software developers must achieve and maintain a shared focus, encourage and challenge each other, and manage their working relations, even in stressful situations. This article describes six key ways professional software developers do this using examples from a video study of professional developers designing at a whiteboard.

A paper on social network sites in government

I’ve written a paper with Ian Sommerville about how social network sites are used in a Government department (The Home Office).  The paper is online here.

John Rooksby & Ian Sommerville (2012) The Management and Use of Social Network Sites in a Government Department. The Journal of Computer Supported Cooperative Work (in press).

In this paper we report findings from a study of social network site use in a UK Government department. We have investigated this from a managerial, organisational perspective. We found at the study site that there are already several social network technologies in use, and that these: misalign with and problematize organisational boundaries; blur boundaries between working and social lives; present differing opportunities for control; have different visibilities; have overlapping functionality with each other and with other information technologies; that they evolve and change over time; and that their uptake is conditioned by existing infrastructure and availability. We find the organisational complexity that social technologies are often hoped to cut across is, in reality, something that shapes their uptake and use. We argue the idea of a single, central social network site for supporting cooperative work within an organisation will hit the same problems as any effort of centralisation in organisations. Fostering collective intelligence in organisations is therefore not a problem of designing the right technology but of supporting work across multiple technologies. We argue that while there is still plenty of scope for design and innovation in this area, an important challenge now is in supporting organisations in managing what can best be referred to as a social network site ‘ecosystem’.

Did the Computer Cause the Crash? (1988)

Almost 25 years ago, Lester Thurow wrote an article in Technology Review (February-March 1988) called Did the Computer Cause the Crash?  This article was later included in a collection called Panic! by Micheal Lewis - which is where I found it.  In the article, Thurow points out that to blame computerisation for the 1987 crash is to blame a tool.

Computers make program trading possible because they can monitor more information faster and give the appropriate buy or sell orders long before a human could figure out what to do.  However, the techniques of program trading and the software used to practice them are very much human creations.  Like all expert systems, they merely mimic the actions of a human expert, in this case a broker.  Thus, to blame the markets rapid fall on the fact the computers are automatically executing decisions that brokers would have made anyway is to make the common mistake of blaming the tool for the actions of the people using it.

Algorithmic trading has moved on since Thurow wrote his article in 1988.  Thurow’s point that decision making in automated trading is essentially a faster version of how humans trade, is no longer true - not wholly true at least.  Its also clear now that algorithms can lead to much faster, much deeper crashes.  But I think it is as necessary now as it was then to draw attention to the people who create and operate computer trading systems.

A recent article by John Bates in the Huffington Post called “Al Gore Blames Algos, But Humans are at fault” makes a somewhat similar point to Thurow.  Bates is criticising something Gore said about algorithmic trading leading to short-termism. 

Algorithms are programmed by people, and it is people that are taking the short term view. While I understand the frustration that high volatility can cause investors, to blame the automation of transactions for short-term HFT strategies is naive. Automation is the single most important thing that has happened to markets, making them cheaper, more transparent and more liquid.

Bates goes on to say:

There is little excuse for financial firms allowing errors, fraud and market abuse to happen. The problem is not the trading algorithms, but the corporate culture instead. If the CEO or head of trading wants to grab a big bonus in a short period of time he or she may well take chances or even break the law.

A lot of people talk about “culture” in trading organisations - and rarely in positive terms.   I think its interesting that to some, algos are symptomatic of this culture, to others they are producing it.  For Bates, culture is something getting in the way of the effective use of tools. 

I’m not sure that culture is the best starting point for a study of trading, especially when the dominant discourse in this area is of cultures-of-greed.  But I think there is certainly something interesting going on here in terms of people and organisations.  There’s also something interesting going on in how we identify and talk about the causes of financial strife and failure.

Work and Automation in Financial Trading

Since the May 2010 Flash Crash there has been much interest in algorithmic and high frequency trading.  In particular, a Foresight Review was commissioned by the UK Government to investigate the future of computer trading in financial markets.  I’ve been reading through their working papers and driver reviews, and - while there is clearly some fantastic research being done in this area - I wonder if much of it is making a classic mistake regarding automation. This may sound counter intuitive but Automated systems do not run themselves.  

A fairly well known paper in the control systems literature, Bainbridge’s “Ironies of Automation” points out that automated systems require human beings for supervision, adjustment, maintenance, expansion and improvement.  Automated systems are heavily reliant upon human work, and so while such systems will make some forms of labour redundant, new forms of labour often emerge around them (there may well be fewer people needed now, but that is not the point).  Few systems are ever left running without some form of supervision or modification for more than a short time. 

There may be fewer human traders than ever, but it is very likely that new roles and new responsibilities are being created.  As Bainbridge points out, systems engineers often fail to understand that their systems will almost inevitably require human intervention, and therefore support for those interventions is lacking.  I think we are in danger of this happening in automated trading.  I think the Foresight Review is making four or maybe five key mistakes:

1. It discusses the markets in structural terms focusing on trading processes.  This kind of modelling is important but does not present the full picture.  Firstly, if people are no longer required for bureaucratic operations but to supervise, adjust, maintain etc. then it is hard to represent them within a process.  Secondly, new work may be emerging beyond where the boundaries of the market structure are currently being drawn.  For example, datacentre and network management, software development, and strategic planning may no longer be beyond the scope of the problem.    
   
2. Too much emphasis is placed on the Flash Crash and the general possibility that huge losses can be made in minutes.  Certainly the Flash Crash woke many people up to the problems in this area, but I think too much emphasis is now being placed on problems that occur at speeds faster than anyone can react.  Essentially speed is being used as a way to dismiss human factors.
3. It discusses the sociology of the markets, but this focuses purely on the social relations between traders that are being lost rather than reconfigured or are emerging.  Technology is being treated as something that replaces social relations. 
   
4. The review is focusing on the dependability of financial markets, but not on dependability from the point of view of organisations operating in this market.  I think both perspectives are important.  As it stands, I think the market view leads to too much emphasis being placed on market level regulation.
   
5. Finally, a somewhat academic problem is that systems theory is drawn upon in parts of the report, and yet much of systems theory - if you trace it back - is premised on the idea that financial systems (and biological systems) are stable.  Surely the point of the review is that this is not the case (at least for financial systems).
   

I find it odd that the review draws extensively from sociologists - in particular the work of Diane Vaughan - and yet no recommendation seems to be made that there is a need for social studies to be undertaken in this area in the future.  Vaughan’s work is used to justify the creation of a market simulator - something that I don’t think is a bad idea - but something that is very different to how Vaughan has influenced researchers at NASA (see for example the paper from David Woods and Jennifer Watts-Perotti that appeared in the Diagnostic Work issue of the CSCW Journal I co-edited a few years ago).

So - research I’m trying to do is figure out what new forms of work are emerging in this area and what new skills are required.

Testing and Demonstrating

Volvo has been working on an automated braking system.  This YouTube video shows a test in which the system fails, and the car plows into the back of a truck.  I’m told (by a thoroughly unreliable source - one of my colleagues) that the problem was with the car battery - it had been put on “quick charge” before the test, and for some reason this led the battery to fail.  Volvo came in for ridicule over this test (and others - there are several videos to be found on YouTube of autonomous vehicles crashing).  I doubt the videos are good for business, and the person who pointed them out to me says they are putting the future of driverless cars into doubt.  People just aren’t confident about autonomous vehicles.

The thing is, in systems engineering terms, this test is “successful”.  Technologies are tested in order to find faults, not show their absence.  To paraphrase Glenford Myers Testing can never prove the absence of faults, but can be very helpful for showing their presence.  In systems engineering then, a “successful” test is one that finds something wrong.  … At least in theory.  In the test in question, I am certain Volvo discovered something valuable - that there was a problem with the “quick charge” setting for the battery.  No doubt they have fixed it now.  The issue is that this test was done in front of an audience.  In this situation testing becomes demonstrating.  A successful test is not a successful demonstration.   A successful demonstration is not a successful test.

On the 17th July 1984 an organisation called CEGB tested a flask designed for transporting nuclear materials by rail - by ramming a locomotive and three carriages into it at 100mph.  The chairman of CEGB described it as “the most horrendous and pessimistic crash we could arrange”.  The flask withstood the impact (you can see a big group of people standing around it near the rear train carriage in the image above).  This test reassured a skeptical public that transporting nuclear materials was safe.  However - as a test - this exercise was fairly worthless.  Look at the picture above and ask yourself why the tracks stop where they do?  Notice all the nice, soft mud.  The train is a Type 46 locomotive, which has a relatively “soft nose”.  The wheels had also been removed from the flask and the carriages weighted so as not to ride up over the engine.  This was a demonstration designed to show the system working - not a test designed to make it fail.   

On the 1st December 1984, NASA and the FAA tested AMK (anti-misting kerosene) - fuel modified in such a way that it was less likely to ignite and burn severely in the event of a crash.  The test involved crashing a remote controlled 747 aircraft, wheels-up, just short of a runway.  To make the situation more extreme, giant cutters were embedded into the runway (you can see them in the image above).  The plane crashed, exploded and was destroyed by fire.  To the observing media the test appeared to be a catastrophic failure.  But the explosion was caused when one of the engines hit a cutter, stopping the turbine and causing a massive release of energy.  The subsequent fire was much slower to spread and passengers would have had some time to disembark (although it is very unlikely anyone would have actually survived the impact).  The test was designed to push the system to extremes, and the resulting data led to insights about how fire spreads in the event of an AMK fueled plane crash.  It was a successful test.  However, it effectively led to the cancellation of the project.

I’m not sure where this leaves Volvo.  I think the video shows them demonstrating a system rather than testing one.  But maybe we should be pleased that Volvo’s demos aren’t quite as carefully stage managed as CEGB’s.  Maybe we should be more concerned when Volvo’s demonstrations start going smoothly.  Certainly, when it comes to testing, we shouldn’t be quick to laugh when tests are successful.  When it comes to testing, we mustn’t put pressure on testers to show that a system works.  Its much easier to video vehicles being tested than many other forms of autonomous system, and we need to be careful that the increasing availability of such video does not lead to a reluctance to test them to extremes.

The train and plane crash tests are discussed in The Golem at Large by Collins and Pinch.  The train crash image comes from here.  The plane crash from here.

Volvo discuss their 2020 vision here.

Notes on “ultra-large-scale systems”

The term “ultra-large-scale system (ULSS)” was introduced in a 2006 report produced by Linda Northrop and colleagues from Carnegie Mellon University’s Software Engineering Institute.  The ULSS report explains that systems are reaching unprecedented scales (by measures including lines of code; numbers of users and stakeholders; purposes the system is put to; amounts of data stored, accessed, manipulated, and refined; numbers of connections and interdependencies among components; and numbers of hardware elements).  The ULSS report argues that these “ultra-large-scale systems” defy traditional approaches to engineering and management.  The problem is no longer of engineering systems, or system-of-systems but of engineering what they call socio-technical ecosystems.

At a similar time to the publication of the ULSS report, a research and training initiative was starting in the UK on Large Scale Complex IT Systems (LSCITS) - the initiative I’m currently employed on.  Many of the challenges recognised in this initiative were the same as, or were similar to those recognised as the challenges of ultra-large-scale systems.  The only significance difference seems to be that the ULSS report argued that we need new engineering approaches in order to build a ULSS, whereas the LSCITS initiative argued that we need new approaches so that we don’t build ultra large scale systems that are unnecessarily risky (see lecture 10 here for a brief discussion).  True to national stereotypes the Americans were asking how can we build the biggest systems in the world?  The British were asking how can we stop screwing up when we try to build the biggest systems in the world?         

The ULSS report explains that ultra-large-scale systems hold the characteristics of systems-of-systems.  They are systems that have operationally independent sub-systems; managerially independent components and sub-systems; evolutionary development; emergent behaviour; and geographic distribution.  But, in addition to these, ULSS will:

• Have decentralised data, development, evolution and operational control.
• Addresses inherently conflicting, unknowable, and diverse requirements.
• Evolve continuously while it is operating, with different capabilities being deployed and removed.
• Contain heterogeneous, inconsistent and changing elements.
• Erode the people system boundary. People will not be just users, but elements of the system and affect its overall emergent behaviour.
• Encounter failure as the norm, rather than the exception, with it being extremely unlikely that all components are functioning at any one time.
• Require new paradigms for acquisition and policy, and new methods for control.

In 2008, Greg Goth wrote in IEEE software that although the ULSS report focused on challenges faced by the United States Department of Defense in engineering software intensive systems, “its description of how the fundamental principles of software design will change in a global economy … is finding wide appeal”. The term is now used to discuss problems in several domains:

Defense: Northrop’s ULSS report argued that

“the U.S. Department of Defense (DoD) has a goal of information dominance … this goal depends on increasingly complex systems characterized by thousands of platforms, sensors, decision nodes, weapons, and warfighters connected through heterogeneous wired and wireless networks. … These systems will push far beyond the size of today’s systems by every measure … They will be ultra-large-scale systems.”

Financial Trading: Cliff and Northrop have argued

“The very high degree of interconnectedness in the global markets means that entire trading systems, implemented and managed separately by independent organizations, can rightfully be considered as significant constituent entities in the larger global super-system. … The sheer number of human agents and computer systems connected within the global financial-markets system-of-systems is so large that it is an instance of an ultra-large-scale system, and that largeness-of-scale has significant effects on the nature of the system”.

Healthcare: Kevin Sullivan, speaking at the IOM, claimed that in the light of the US HITECH act:

[The US healthcare system is] “clearly an ultra-large-scale system”

and that

[building national scale cyber-infrastructure for healthcare] “demands not just a rigorous, modern software and systems engineering effort, but an approach at the cutting edge of our understanding of information processing systems and their development and deployment in complex socio-technical environments”.

I’d argue that the NHS in England is facing similar issues.  This is not to argue that individual technologies produced under NPfIT are in themselves ultra large scale systems, but that the NHS is facing massive problems of integration, interoperation and coordination.

Other Domains: Other domains said to be seeing the rise of ultra-large-scale systems include government, transport systems (for example air traffic control systems), energy distribution systems (for example smart grids) and large enterprises.

I’ve recently updated the Wikipedia page on ultra-large-scale systems.  Ian Sommerville has also added an entry about LSCITS.

Tumblr blog

I’m switching from using customised Tumblr pages for my blogs, to using the API.  I’ve found writing and managing my own Tumblr themes too fiddly.  The Javascript below is a modification of something written by @stuaart .  It uses version 1 of the API.  Tumblr released API V2 last July - I’ll write/modify something using that when I have time.

<head>

…

<script type=”text/javascript” src=”http://YOURBLOGNAME.tumblr.com/api/read/js”>

</script>

<script type=”text/javascript”>

function blog()
{
  for (var i = 0; i < tumblr_api_read.posts.length; ++i)
  {
    var post = tumblr_api_read.posts[i];

    document.write(“<div class="YOURCSS">”
                   + post[“date”]
                   + “<em> - ” + post.type + “- </em>”
                   + “<a href="” + post.url + “">permalink</a></div>”
                   + “<div class="YOURCSS">”);

    switch (post.type)
    {
      case “regular”:
      {
           document.write(“<div class="YOURCSS">”
              + post[“regular-title”]
              + “</div><div class="YOURCSS">”
              + post[“regular-body”]
              + “</div>”);             
      }
      break;

      case “photo”:
      {
        document.write(“<div class="YOURCSS">”
            + post[“photo-caption”]
            + “<center><img src="”
            + post[“photo-url-400”] + “" /></center></div>”);           
      }
      break;

      case “quote”:
      {
        document.write(“<blockquote><h2>"”
            + post[“quote-text”] + “"</h2></blockquote><div class="YOURCSS">”
            + post[“quote-source”] + “</div>”);                   
       }
       break;

      case “video”:
      {
        document.write(“<div class="YOURCSS">”
              + post[“video-caption”] + “</div>”);
        document.write(post[“video-player”]);
      }
      break;
        
         case “link”:
      {
         document.write(“<div class="YOURCSS"><a href="”
                + post[“link-url”] + “">” + post[“link-text”]
                + “</a>”
                + post[“link-description”] + “</div>”);
      }
      break;
        
         default:
        {
        document.write(“<div class="YOURCSS">”);
        document.write(“<em>Error reading blog entry (type: ” + post.type + “) <a href="http://YOURBLOGNAME.tumblr.com">YOURBLOGNAME.tumblr.com</a></em></div><br>” );
        }
      break;
     
    }

    document.write(“</div><br>”);

  }
}

</script>

…

</head>

…

<script type=”text/javascript”>document.onload = blog();</script>