This position paper deals with the exploration of tness and evolvability of personal learning environments (PLEs). Taking a software engineer's perspective, PLE evolution is a software project. Software quality characteristics like Functionality and Usability map to the PLE's tness, while Maintainability is important for evolvability. Only adaptation can secure future tness. But for this, the software project has to be a good PLE for its developers in its on right.
Common wisdom of software development | going back to Edward V. Berard | says: \Walking on water and developing software from a speci cation are easy if both are frozen." The success of Personal Learning Environments (PLEs) not only depends on their tness for a certain purpose or environment, but no less than this depends on their ability to evolve, i.e. to adapt to changes. In the world of software, the continuous change of requirements is as sure as death and taxes. A PLE that fails to catch up with new requirements, ages and eventually becomes useless.
Bear with me, while I relate to the workshop's natural
evolution metaphor: The extinction of dinosaurs is attributed to
their failure to adapt to a changing environment. Their races
showed only few diversi cation and innovativeness in
behavioral strategies. When their world changed, only two species
attempted an adaptation to new foods [
Predominance and wide spread were limited predictors of tness and evolvability. Predominance can suppress competitors, but for how long? It is no disgrace to wait for a chance like the early mammals. To avoid extinction and eventually prevail, PLEs must evolve. Di erent from nature, where mutation of organisms occurs by accident and without the intent to optimize a creature's tness, adaptation happens through conscious decision and human developers.
I take on a software engineer's view in the discussion on tness and evolvability of PLEs. In this view, evolvability E is understood as a PLE's ability to embrace natural change, i.e. evolution E0. Fitness F does not imply evolvability, nor does evolvability imply tness. Yet both are prerequisites of successful evolution F ^ E ( E0. New clades of PLEs often start from research. While tness is usually tested thoroughly there, evolvability is often neglected.
The easier developers perform changes, the higher the chance that a PLE will cope with emerging requirements. Only this can make a PLE remain t. Section 2 addresses the ease of change in software projects. This leads to the nding that learning is essential, and to the dualism that evolution is a PLE itself (Section 3). As long as a PLE's tness su ces to safe it from extinction, evolvability is most important. A more evolvable PLE will adapt to changing environmental demands faster and easier. In conclusion, this is not least a matter of how easy PLE developers can obtain the necessary knowledge to make change happen. 2.
Evolvability means to be prepared for changing
environments and the unknown. It cannot be said in an
across-theboard fashion what that practically means. It would imply
to summarize the achievements of software engineering in a
few sentences. In the Iron Triangle, the prime resource is
people supported by processes and technology [
Whenever a software system grows larger, its
complexity increases to a level that is no longer easily handable.
Any successful software will eventually grow to that size.
Abstraction and structuring that organize it into an
understandable architecture become necessary. A good
architecture means that developers can change parts without having
to understand everything. But for the individual developer,
having to adhere to architecture rules can be cumbersome.
In a multi-tier Web-Service project, developers of front-end
components bypassed the middle layer, and directly accessed
back-end layers. This sped up development at rst, but
degraded architecture to a costly mess. Evolvability
assessment should take into account how an architecture is
protected, and how technical debt (see also [
The term architecture should not be confused with
integration platform. An integration platform can be something
like UNIX's toolbox concept with its many small programs.
It can be Web-Services, or a single program based on OSGi.
The di erent platforms have di erent strengths and
weaknesses that in uence PLE tness. Yet from an evolvability
point of view, they are similar, all allowing fast adaptation
through reuse of components. Do not think that a
technology has reuse built in; instead, reuse is a discipline [
Even with the best architecture, building a software
architect's knowledge costs a hundred million. The combination
of deep domain knowledge and system engineering
capabilities is invaluable [
Is the business model associated with the PLE project sustainable? While a potent company may be able to handle closed-source evolution on its own, also the openness of open source | mind the license | has advantages for evolvability: open standards, interoperability, cost e ectiveness, attractiveness for users, possibly unlimited branching and experimentation, and a higher number of potential developers. However, a major road block to becoming a productive executor of PLE evolution, is knowledge about the software.
The Maintainability quality characteristic describes a
software's capability to be modi ed and evolve [
All of the aspects in the paragraphs above, help developers to understand the software by being few (complexityreducing architecture), simple (with reuse in mind), supervised (senior architect guidance), open (open source), and 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 of PLE evolution a software project, but a software project is a PLE itself. This duality is addressed next, when we look at internal documentation, which can be considered as the learning material that supports learning a software system.
Modern software systems are too complex to fully
understand them. But a certain understanding is necessary
for performing changes. Working on a computer system is
therefore a continuous learning process. The learning
materials are process artifacts like source code, requirements,
bug history, etc.; a developer's PLE consists of his individual
selection of source code pieces, requirements, searchable bug
records and so on that are delivered to him through tools
like an IDE or an issue tracker. Developers do not like to
create such learning material because it has few value for
them [
Consider the example of source code (see also [
In a small, one-person, throw-away-prototype project it
may be su cient to just code, but any other project will
eventually need documentation [
Documentation (as learning material) communicates
background, context, and trial-and-error information. This
information is extremely valuable [
Evolvability is important for the success of a PLE, because it allows to adapt it to new environments, and thus stay t. PLE evolution happens through a software project. Developers, who realize the change of evolution, require a certain knowledge of the software for this. Evolvability then is the availability and ease of obtaining the necessary knowledge.
After all, a PLE's evolution, i.e. its software project, is a PLE in its own right. This duality between software projects and PLEs is the key to evolvability, and future tness. Does the software project make a good PLE for its developers? If yes, then a big obstacle to survival is cleared out of the way.
This paper was invited by the EFEPLE workshop and supported by the CAPLE project. 5.