Software Factory is a platform for research and education. It maintains close contact to industry and fosters entrepreneurship by collaborating with small companies and students who are considering a future as software entrepreneurs. At the end of 2009, I joined a project to design and build the first factory at the Department of Computer Science, University of Helsinki. In this article, I relate my experiences with managing this complex project.
During the doctoral consortium of PPIG 2010 in Madrid, several fellow doctoral students expressed their woes over lack of good data for their research. In general, availability of good data sources is limited. Any kind of PPIG-related research that requires dealing with human subjects has this same problem – and it is hard to imagine how most PPIG-related research could avoid human subjects. Part of the difficulties arise because interesting projects often happen where you cannot study them in detail. For example, companies may not want to open their doors for researchers who have not yet proven themselves – but to prove themselves they would need access to high-quality, valid data. Open Source project participants may be reluctant to answer yet another online questionnaire – where is the benefit for them?
Also, if you do get an opportunity to study real-life projects, the degree of control over experimental variables can be very low. Even as a project intern, you must often do with what you get, which is to accept the fact that you cannot intervene or manipulate independent variables to the degree that you would like. When the most interesting moment comes – for example, the realisation that a project may have to reduce its scope because of schedule concerns – you may be excluded from the discussion because it will occur at a higher managerial level. The basis for the final decision may be political, and your ability to draw conclusions relevant to your research will be limited. At best, you will get good data for an interesting case study. At worst, your experiment will become invalid.
In 2009, while discussing funding of my PhD work, my former MSc supervisor hinted at the possibility of a new project starting at the Department of Computer Science, University of Helsinki (CS department). I started to get involved in discussions concerning this project, and in the autumn of 2009 I was offered a position in the project. Pekka Abrahamsson, the visionary professor behind the project, needed someone to lead and coordinate planning, construction and initial operation of what was then known as a global software research lab.
The vision was of an environment to support research, education, and entrepreneurship. In professor Abrahamsson's words, software engineering research often lacks industrial impact, current studies are poorly generalised, and many results are never commercialised or understood by industry. In education, universities may expect industry to educate students about real software development. Academic educators are rarely exposed to real development complexities like restraints on cost and schedule. [Abrahamsson 2009]
The vision also painted a picture of what this environment would be in the physical world: a Software Factory with 12-15 developers working regular business hours, doing real-life software development with business goals, deadlines, delivery dates, real stakeholders, end-users and other complexities that are common in software design and development. It would be an actual facility equipped with all the necessary tools for modern software development. It would also be possible to record entire projects in high-definition video with multiple cameras to allow researchers to study software development in detail as it unfolds. The vision also had a global dimension: several similar factories would be set up around the world to simulate distributed software projects. [Abrahamsson 2009; personal communication; Abrahamsson 2010]
As we explored this vision, new ideas emerged. The educational aspect grew, and we realised that this was an opportunity to support masters- and doctoral-level education, and to exercise the so-called third mission of the university: to bridge the gap between university and society by allowing budding entrepreneurs to reach out, and existing businesses to reach in. This would also ensure that we would have a set of interesting project ideas with backing from motivated domain experts. [Kurhila 2010; Kettunen 2010a; Kettunen 2010b]
As most visions, this one was optimistic about schedules, and omitted some restrictions imposed by reality. Our funding was secured until the end of the year, which was only three months away. If we could not deliver something tangible by then, the vision would probably never take form. My challenge was to make the vision concrete and decide what needed to be implemented first. With less than three months at my disposal, I soon began to doubt whether it was possible to reach any goal at all. But I had already begun developed a vision of my own: I knew what the end result should be like. I had the choice of trying to implement it, or to let it remain a dream. I chose the former.
With so little time on my hands, delegation was the only possibility. I started involving people, letting them know about the vision, and letting them go to work, planning and implementing in very short cycles, sometimes just hours. In line with good project management, I made sure everyone's intermediate goals were as clear as possible, and in Lean fashion, I made sure that there was as little waiting as possible – making efforts run in parallel wherever feasible.
We already had secured the facility – a project room at the department – and basic construction work could start without further elaboration. We cooperated with an interior design firm to make a modular floor plan with the major activity areas mapped out: tables for working, a sofa for resting and socialising, and "hot spots" with accompanying group work equipment to facilitate information sharing and visualisation. The major structures along with electricity and network were already in place. I contacted the building architect, who connected me with key persons in the Premises and Property Services at the university. We added additional electrical outlets, lighting, and found a solution for bringing cabling to work tables in a discreet and safe way.
In parallel, I worked with the university's audiovisual services to find suitable solutions for the video and audio recording equipment. My background in media helped formulate our requirements in sufficient detail, including what types of camera angles we were looking for, what kind of lighting conditions we could expect, what the technical specifications for image quality would be, and so on. The audiovisual services staff also had experience with several kinds of group work equipment, and we chose a SmartBoard to enable collaborative and interactive planning. We also wanted to provide our software development teams with the ability to visualise their work, and settled on a three-by-three screen information radiator that the team could program with whatever visualisation was suitable for them. Finally, we also installed traditional whiteboards, which are reliable and can be used for multiple purposes.
Also in parallel, I worked with the CS department's computing facilities and Helsinki Institute for Information Technology HIIT staff to get development workstations, monitors, and the building blocks for the information radiator. Also, they provided IP networks for the factory and video equipment, hosting for the network video recorder, disk space in their SAN, and an internal wiki and version control system.
Recording entire projects is challenging not only technically, but also from a legal and ethical perspective. Ethical issues are highly relevant for software research [Singer 2002]. I realised early on that this aspect was largely neglected in the visionary ideation. It is easy to forget that computer science is not only a mathematically or technically oriented field, there are humans involved that can become research subjects even if the research is primarily concerned with software and development processes. They can also be the primary focus of the research in some cases. Not being a lawyer, all I could do was gather the needed information, present it to my group, and make sure I had provisions for handling all data in the correct manner. Some specific details had to be in place: there had to be a separate, secure network for the video data, and it had to be stored securely and be accessible only to persons who needed it.
There was also the question of copyrights: who owns the works produced in the factory? I discovered there was little knowledge in my group about copyrights, patents, and other intellectual property concepts. They mostly seem to be considered a nuisance that is put off as long as possible. Another course at the CS department had had similar needs in the past when working with industry partners. In that course, participants either all licensed their work under an open source license, or they transferred their copyright to the industry partner. In this case, however, support for a more diverse range of scenarios was needed. In addition to the open source and complete transfer alternatives, there was also the possibility of several academic and industry partners in a single project, continuation projects where previous rights holders would not necessarily be available to approve further use of their works, and projects targeting a spinoff company. The university's legal department helped draft a contract that would enable the first step to support these scenarios.
Software Factory became operational in January 2010. The first project was launched on the 18th of January, and was concluded seven weeks later, on the 15th of March. From the first day of operation, Software Factory has been a platform that solves the problems of data acquisition and access to projects. For researchers, it provides a testbed for research methods and for doctoral training. For students, it provides a valuable learning experience to prepare them for project work in software development organisations. For entrepreneurs, both external to the university and to students wishing to start their own company, it provides an environment where ideas for software products and services can be taken to a prototype stage.
Software Factory has now been operating for a year and a half at the CS department. We have been able to try several kinds of studies, ranging from qualitative, observation- and participation-based research, to quantitative analysis of project metrics. Our master's students have appreciated the opportunity to study real projects for their masters theses, and PhD students have been able to train research skills needed in complex projects.
Participation in Software Factory currently is in the form of a course. Each course corresponds to a project – however in some cases, several projects might be run in the same course, if they have common elements or are small enough. The course is far from easy. Students participating as development team members have the responsibility to carry out the project from start to finish. There is no "pause button" that can be used to get more time for the project; the deadline is known in advance and students must balance time, resources, and requirements as in a real project. Our experiences so far have shown that our students differ greatly in technical skills, motivation, and ability to participate actively and take initiative in the projects. Personally, I think of this as a positive challenge: how can we develop the course and the rest of the curriculum to support the skills needed in complex software development projects?
Until now, Software Factory has predominantly been a single-site environment. However, modern software development often occurs in a distributed setting, with several sites collaborating on the same project. The ultimate goal of Software Factory is to have a number of factories around the world which can be connected on demand to collaborate on common projects. This would allow research and education in Software Factory to be on the same level as state-of-the-art software projects. The first steps towards this have already been taken: the University of Eastern Finland, Joensuu campus, have applied the Software Factory concept in their own setting. The first video conference has been held, and in 2011, we have carried out two joint projects. We are also expecting sites in Spain [Martín Ruiz et al. 2010] and Italy to join our collaboration. Meanwhile, we are moving our own Software Factory to a bigger room, so that we have the space necessary for bigger projects and communication equipment for distributed development.
Education in Software Factory bears little resemblance to traditional university lectures. It is also different from other lab projects at the CS department because such a large responsibility is placed on the students. Had I been offered such a course during my master's studies, I would not have hesitated to take it. Having worked in the software industry, I also know that the skills that can potentially be learned during a Software Factory project are invaluable in the workplace. However, it is not clear exactly what these skills are, how to ensure that they are being learned, or how to grade students in this kind of a project. I have taken some initial steps, but there is much to be learned about learning in this kind of an environment.
Finally, a valuable contribution to the field of software research would be the release of a rich software project data set. Many other fields have standard data sets that are used in education and method development, but software research lacks a set of complete project data. The legal and ethical challenges are great, since we must balance between the confidentiality and anonymity of research subjects, and open access to enable meaningful research. This will be one of the great challenges for Software Factory in the coming years.
Software Factory extends an open invitation to join our network of factories working to advance research, education, and entrepreneurship in the field of software. Setting up a Software Factory at your university requires a lot of work and some resources, but we have made the process easier and can give helpful advice and blueprints. With some dedication, you can build it in less than three months. (It has been proven possible...)
[Abrahamsson 2009] Abrahamsson, P.: Global Software Laboratory Vision. Unpublished slide set. September 2009.
[Abrahamsson 2010] Abrahamsson, P., Kettunen, P., Fagerholm, F.: The Set-Up of a Valuable Software Engineering Research Infrastructure of the 2010s. The 11th International Conference on Product Focused Software Development and Process Improvement (PROFES 2010) / Workshop on Valuable Software Products (VASOP 2010). June 2010.
[Kettunen 2010a] Kettunen, P.: Strategic outlook: Software Factory fosters next-generation software production and business. Software Software Factory Magazine. Volume 1, January 2010, p. 5.
[Kettunen 2010b] Kettunen, P.: Software Factory research helps in factoring high-performance software enterprises – even at large scale. Software Software Factory Magazine. Volume 1, January 2010, p. 7.
[Kurhila 2010] Kurhila, J.: Educational perspectives in Software Factory. Software Software Factory Magazine. Volume 1, January 2010, p. 6.
[Martín Ruiz et al. 2010] Martín Ruiz, Juan Luis and Yagüe, Agustín and Gonzales Ortega, Eloy and Garbajosa, Juan: Making Software Factory truly global: the Smart Software Factory Project. Software Software Factory Magazine. Volume 1, January 2010, p. 19.
[Singer 2002] Singer, J. and Vinson, N.: Ethical Issues in Empirical Studies of Software. IEEE Transactions on Software Engineering Engineering, Vol. 28, Issue 12, December 2002, pp. 1171-1180.