A Software Project Perspective on the Fitness and Evolvability of Personal Learning Environments Christian R. Prause Fraunhofer FIT Schloss Birlinghoven, Sankt Augustin, Germany christian.prause@fit.fraunhofer.de ABSTRACT thoroughly there, evolvability is often neglected. This position paper deals with the exploration of fitness and The easier developers perform changes, the higher the evolvability of personal learning environments (PLEs). Tak- chance that a PLE will cope with emerging requirements. ing a software engineer’s perspective, PLE evolution is a Only this can make a PLE remain fit. Section 2 addresses software project. Software quality characteristics like Func- the ease of change in software projects. This leads to the tionality and Usability map to the PLE’s fitness, while Main- finding that learning is essential, and to the dualism that tainability is important for evolvability. Only adaptation can evolution is a PLE itself (Section 3). As long as a PLE’s secure future fitness. But for this, the software project has fitness suffices to safe it from extinction, evolvability is most to be a good PLE for its developers in its on right. important. A more evolvable PLE will adapt to changing en- vironmental demands faster and easier. In conclusion, this is not least a matter of how easy PLE developers can obtain 1. INTRODUCTION the necessary knowledge to make change happen. Common wisdom of software development — going back to Edward V. Berard — says: “Walking on water and de- veloping software from a specification are easy if both are 2. EMBRACING THE CHANGE frozen.” The success of Personal Learning Environments Evolvability means to be prepared for changing environ- (PLEs) not only depends on their fitness for a certain pur- ments and the unknown. It cannot be said in an across-the- pose or environment, but no less than this depends on their board fashion what that practically means. It would imply ability to evolve, i.e. to adapt to changes. In the world of to summarize the achievements of software engineering in a software, the continuous change of requirements is as sure few sentences. In the Iron Triangle, the prime resource is as death and taxes. A PLE that fails to catch up with new people supported by processes and technology [5]. A full dis- requirements, ages and eventually becomes useless. cussion of all three factors would be way out of scope of this Bear with me, while I relate to the workshop’s natural evo- paper. Instead, here are some fundamental considerations: lution metaphor: The extinction of dinosaurs is attributed to Whenever a software system grows larger, its complex- their failure to adapt to a changing environment. Their races ity increases to a level that is no longer easily handable. showed only few diversification and innovativeness in behav- Any successful software will eventually grow to that size. ioral strategies. When their world changed, only two species Abstraction and structuring that organize it into an under- attempted an adaptation to new foods [6]. The dinosaurs’ standable architecture become necessary. A good architec- seemingly unbreakable predominance abruptly ended, mak- ture means that developers can change parts without having ing room for mammals that had waited in a niche. Mam- to understand everything. But for the individual developer, mals instantly filled the gap, and diversified into a plethora having to adhere to architecture rules can be cumbersome. of species. Today, they emboss the planet’s face as successful In a multi-tier Web-Service project, developers of front-end predators. If dinosaurs had not failed to adapt, they would components bypassed the middle layer, and directly accessed have remained invincible competitors for any other species. back-end layers. This sped up development at first, but de- Predominance and wide spread were limited predictors of graded architecture to a costly mess. Evolvability assess- fitness and evolvability. Predominance can suppress com- ment should take into account how an architecture is pro- petitors, but for how long? It is no disgrace to wait for tected, and how technical debt (see also [1]) is dealt with. a chance like the early mammals. To avoid extinction and The term architecture should not be confused with inte- eventually prevail, PLEs must evolve. Different from nature, gration platform. An integration platform can be something where mutation of organisms occurs by accident and with- like UNIX’s toolbox concept with its many small programs. out the intent to optimize a creature’s fitness, adaptation It can be Web-Services, or a single program based on OSGi. happens through conscious decision and human developers. The different platforms have different strengths and weak- I take on a software engineer’s view in the discussion on nesses that influence PLE fitness. Yet from an evolvability fitness and evolvability of PLEs. In this view, evolvability E point of view, they are similar, all allowing fast adaptation is understood as a PLE’s ability to embrace natural change, through reuse of components. Do not think that a tech- i.e. evolution E 0 . Fitness F does not imply evolvability, nor nology has reuse built in; instead, reuse is a discipline [12]. does evolvability imply fitness. Yet both are prerequisites Here, it is more important to look at the processes. of successful evolution F ∧ E ⇐ E 0 . New clades of PLEs Even with the best architecture, building a software archi- often start from research. While fitness is usually tested tect’s knowledge costs a hundred million. The combination 49 of deep domain knowledge and system engineering capabil- by investing a little more effort. Source code — originally ities is invaluable [2]. Will the architect stay with the PLE a medium of communication between man and machine — project? What endeavors are made to train new architects? has become a medium of communication among humans [3]. Is the business model associated with the PLE project Documentation (as learning material) communicates back- sustainable? While a potent company may be able to han- ground, context, and trial-and-error information. This in- dle closed-source evolution on its own, also the openness of formation is extremely valuable [8], but will get lost if not open source — mind the license — has advantages for evolv- preserved. Motivating developers to create good learning ability: open standards, interoperability, cost effectiveness, material is a key to evolvability and survival of PLEs. attractiveness for users, possibly unlimited branching and experimentation, and a higher number of potential develop- 4. CONCLUSION ers. However, a major road block to becoming a productive Evolvability is important for the success of a PLE, because executor of PLE evolution, is knowledge about the software. it allows to adapt it to new environments, and thus stay fit. The Maintainability quality characteristic describes a soft- PLE evolution happens through a software project. Devel- ware’s capability to be modified and evolve [4]. By being opers, who realize the change of evolution, require a certain analyzable, easy and predictable to change, and allowing to knowledge of the software for this. Evolvability then is the test changes, software developers can gain a deep under- availability and ease of obtaining the necessary knowledge. standing of the software through practical experimentation. After all, a PLE’s evolution, i.e. its software project, is a All of the aspects in the paragraphs above, help develop- PLE in its own right. This duality between software projects ers to understand the software by being few (complexity- and PLEs is the key to evolvability, and future fitness. Does reducing architecture), simple (with reuse in mind), super- the software project make a good PLE for its developers? If vised (senior architect guidance), open (open source), and yes, then a big obstacle to survival is cleared out of the way. practical (support experimentation) to learn. Knowledge about the software project, i.e. about how to evolve the PLE, is at the center of evolvability. Not only is the process Acknowledgment of PLE evolution a software project, but a software project This paper was invited by the EFEPLE workshop and sup- is a PLE itself. This duality is addressed next, when we look ported by the CAPLE project. at internal documentation, which can be considered as the learning material that supports learning a software system. 5. REFERENCES [1] W. Cunningham. The wycash portfolio management 3. THE SOFTWARE PROJECT AS A PLE system. In OOPSLA Addendum. ACM, 1992. Modern software systems are too complex to fully un- [2] B. Curtis, H. Krasner, and N. Iscoe. A field study of derstand them. But a certain understanding is necessary the software design process for large systems. Comm. for performing changes. Working on a computer system is of the ACM, 31:1268–1287, November 1988. therefore a continuous learning process. The learning ma- [3] G. Dubochet. Computer code as a medium for human terials are process artifacts like source code, requirements, communication: Are programming languages bug history, etc.; a developer’s PLE consists of his individual improving? In 21st Annual PPIG Workshop, 2009. selection of source code pieces, requirements, searchable bug [4] ISO/IEC 9126-1: Software engineering – product records and so on that are delivered to him through tools quality: Part 1: Quality model, 2001. like an IDE or an issue tracker. Developers do not like to create such learning material because it has few value for [5] A. S. Koch. The people premium. online: http://www. them [9]. But it is needed to persist collaborative long-term projectsatwork.com/content/articles/227504.cfm, efforts like developing and maintaining a software. October 2005. Projects@Work Journal. Consider the example of source code (see also [7]): Source [6] G. T. Lloyd, K. E. Davis, D. Pisani, J. E. Tarver, code is mostly learning material for us humans. There is M. Ruta, M. Sakamoto, D. W. E. Hone, R. Jennings, an infinite number of ways of writing a same-purpose com- and M. J. Benton. Dinosaurs and the cretaceous puter program. Neither does it matter for a computer what terrestrial revolution. R. Soc. B, 275:2483–2490, 2008. programming language one uses, nor does a parser care how [7] C. R. Prause, R. Reiners, S. Dencheva, and functions and methods are named. The instructions that the A. Zimmermann. Incentives for maintaining computer needs are intertwined with the human-readable high-quality source code. In PPIG-WIP, 2010. lines of source code. Functions, data types, objects, com- [8] J. Raskin. Comments are more important than code. ments, macros, etc. and their respective names are just ACM Queue, 3(2):64–62 (sic!), 2005. abstractions that make the design appear more clearly from [9] B. Selic. Agile documentation, anyone? IEEE code by masking unneeded implementation details [10]. This Software, 26(6):11–12, Nov/Dec 2009. way we humans better understand what the computer will [10] D. Spinellis. Code documentation. IEEE Software, do. Programming languages exist so that we can better ex- 27:18–19, 2010. plain to our fellow developers what the computer will do. [11] S. R. Tilley. Documenting-in-the-large vs. document- In a small, one-person, throw-away-prototype project it ing-in-the-small. In CASCON. IBM Press, 1993. may be sufficient to just code, but any other project will [12] M. Wasmund. Reuse facts and myths. In ICSE, 1994. eventually need documentation [11]. The actual way of how code is documented is less important, as long as all the nec- essary information is conveyed. The difference that matters is that between hacking code quick and dirty, or being nice to fellow developers by making code easier to understand 50