Adding and removing modules (also called plug-ins, add-ins and other names) without technical support or supervision is becoming the norm for everyday software applications such as web browsers, image editors and email tools, e.g. Firefox, Photoshop and Outlook. This same approach is becoming important in mobile phone software, where 'in-app purchase' of modules is becoming more and more popular, and a huge money-spinner for developers.
The consequences are not all good: users often do not know which modules to use or change, to suit their goals, or whether a program will crash after such changes. As a result of modules being from different developers, their combination may never have been tested prior to public use. Evaluators and developers struggle to help, because established approaches to software definition, design and analysis are based on the structure of a program being the same wherever and whenever it is used. In constrast, one would be hard put to define a single software structure that accurately describes what a program like Firefox is. Use is similarly hard to pin down, as individuals make systems fit with their own uses and contexts, and share their innovations with others.
As a modular program becomes complex, the result is often a 'plug-in hell' of broken software dependencies, functions, uses and expectations. If, instead, software structure is kept simple, then design opportunities are lost as developers avoid the difficulty and cost of implementing innovative programs. More generally, software theory and engineering have fallen behind practice. We lack ways to reason predictively in a principled way about real world structure and use. We lack tools for designers, evaluators and users that support adaptation, and we lack principles and techniques that can deal with the scale of human and software interaction.
Our primary objective is to deliver a new science of software structures, with design, theory and tools that reflect software in real world use, and able to tackle the complex problem of how to design to support change and appropriation. The key concept is the 'software population': a statistical model of the variety we see when we look at how the same initial program has been used and adapted by its users. A population model is kept up to date by each instance of a program logging how it is used and changed. The population idea affords a common design vocabulary for users' understanding and adaptation of programs, for evaluators' analysis of programs in use, and for developers' making informed changes to the modules available to users.
As a result, users will have programs that may vary but are more comprehensible, robust and adaptable than is the case today. We will enable each individual user to make a practical decision that only he/she is qualified to make: how to balance the changed robustness and functionality of one's system with changes to the system's support for individual and social interactions. One will have tools built into one's program that makes clear what it consists of, and how its structure relates to the programs and experiences of other users. One can find out about other modules that are compatible with one's program, how it will work after adding in one or more new modules, and therefore which configurations of modules will and will not work.
In order to test whether the approach works at the scale of, for example, typical iPhone applications, we will build and deploy programs among large numbers of users, for weeks or months-mobile games and social networking applications. We will work with industrial partners including the Edinburgh Festivals, as well as using popular sports and events, such as soccer (e.g. the 2014 FIFA World Cup Brazil), athletics (e.g. the London 2012 Olympics and the Glasgow 2014 Commonwealth Games), and popular TV programmes. Overall, We plan for 500,000-1,000,000 users of our systems in the course of the programme.
|