=Paper= {{Paper |id=None |storemode=property |title=A Software Project Perspective on the Fitness and Evolvability of Personal Learning Environments |pdfUrl=https://ceur-ws.org/Vol-773/EFEPLE-11-Prause.pdf |volume=Vol-773 }} ==A Software Project Perspective on the Fitness and Evolvability of Personal Learning Environments== https://ceur-ws.org/Vol-773/EFEPLE-11-Prause.pdf
         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