-
-
Save missingfaktor/9c11624b27d980b13e260bc02fe62910 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introduction | |
============ | |
Industry statistics as a whole have failed to improve much since 1968, when software engineering and | |
scientific management were introduced as means for resolving the "software crisis". Unfortunately | |
abandoned projects, cost/time overruns, and bloated, buggy software still dominate the landscape. | |
In spite of the efforts to mitigate this situation --like XP, agile, software craftsmanship or DDD-- the | |
reality is that a usual software project stack involves an increasingly larger number of programming | |
languages, DSLs, frameworks, systems, tools, techniques and processes, so it is a fact that the | |
accidental complexity in our day-to-day software projects is increasing to unbearable levels. | |
As we have conceived the software development we see as natural that once a programmer has | |
adquired enough knowledge about a problem domain and has conceived a mental model for this | |
domain we must wait for days or weeks before seeing a running prototype and maybe months before a | |
production-quality piece of software be ready. | |
We argue that this is an unacceptable consequence of our failed conception about the software | |
development activity, but not an inherent characteristic to the nature of software development. | |
Nowadays, the programming we have invented requires developers to jump continuously between very | |
different thinking levels –-like the conceptual, the source code or the runtime levels-- trying to tracing | |
back and forth between a domain concept and the code that represents it, or between a defect and the | |
affected source code or application benaviour. | |
We claim that programming should be reconsidered as a mainly modelling activity and programmers | |
should be able to capture their applications in an executable domain model from which to obtain | |
running prototypes efforlessly and immediately. | |
In the other hand, we have constrained the developers range of experiences in a tiny subset of their | |
intellectual capabilities: sitting at a desk, staring at a computer screen and typing in a keyboard. | |
We think this is the wrong way to understand or think about a complex system. The right way is to | |
model it and explore it. So we need a new kind of media to create "dynamic models" in real time in the | |
middle of a modeling conversation with other developers or domain experts. | |
We plan to build a new breed of dynamic and fully conceptual modeling environment in order to enable | |
programmers to work through every development stage --analysis, specification, design, | |
implementation, deployment, evolution, etc.-- at the conceptual level and explore their dynamic | |
models as a thinking and learning tool. | |
Previous Work and State of the Art | |
================================== | |
Software engineers are little concerned with the representation and processing of domain knowledge | |
and too much concerned with the solution space considerations. | |
Until now the focus has been on the least tractable representation of the software problem, the code: | |
- Extremely complex. | |
- Hard to reason about. | |
- Hard to change, adapt or reuse. | |
The promise of object-oriented programming, and of programming languages themselves, has yet to | |
be fulfilled. That promise is to make plain to computers and to other programmers the communication | |
of the computational intentions of a programmer or a team of programmers. | |
The failure of programming languages to do this is the result of a variety of failures to take seriously | |
the needs of people in programming rather than the needs of the computer and the language/compiler/framework | |
writer. To some degree, this failure can be attributed to our failure to take seriously the needs | |
of the programmer. | |
Several initiatives have appeared in the last years trying to tackle the software complexity by focusing | |
the team's attention on knowledge of the domain, picking apart the most tricky, intricate problems with | |
models, and shaping the software around those models. | |
Perhaps the most prominent initiative in this direction is the Domain-Driven Design (DDD) approach | |
proposed by Eric Evans in 2003. Since then the DDD principles have been slowly spreaded and | |
adopted by an incipient community of practitioners. In spite of these efforts, most software projects | |
continue both ignoring the relevance of the domain knowledge or doing a poor previous modelling work | |
withouth getting much real benefits at the end. | |
In our opinion, DDD has laid out some useful concepts and practices. However, we pretend to take the | |
DDD phylosophy and vaues until their last consequences in a kind of "Extreme DDD". | |
Work Hypothesis and Objectives | |
============================== | |
It is safe to say that we all share a feeling of unease as far as the general state of software is | |
concerned: development is difficult, achieving correctness is difficult, levels of software reuse are low, | |
feedback loops are too large, etc. | |
In this thesis we explore some of the root causes of this apparent failure, and argue that we need to be | |
bolder in interpreting the original vision of object-orientation. | |
An argument can be made that the contemporary mainstream understanding of objects is but a pale shadow | |
of the original idea. Further, it can be argued that the mainstream understanding of objects is, in practice, | |
antithetical to the original intent. | |
We have identified the following working hypothesis: | |
1. Programming is a representation of thought, so programmers should be able to focus their | |
attention on the problem space rather than the solution space. | |
Our current programming languages and tools appart us far from the domain concepts. Even | |
using those languages relatively bening –-like "pure" object-oriented programming languages-- | |
it is still required too much attention and dedicated effort to the implementation details. | |
2. We must get away from pencil-and-paper thinking and create a new dynamic medium for | |
thinking and learning software. | |
Even when working on the computer, we still think in representations that were invented for the | |
medium of paper. Programming languages are written languages and they were designed for | |
writing. | |
What programmers could think is determined by the language they use and some languages or | |
media allow you to think "better" than others (Sapir–Whorf hypothesis or “linguistic relativity”). | |
To understand or build complex systems, we need powerful new representations, and we need | |
a powerful new medium to work with these representations. | |
Our screens and keyboards are pencil and paper metaphors that constrained us to mostly | |
simple symbolic representations. However in the new medium representations can draws on all | |
the modes of understanding of the human brain like visual, aural, tactile, kinesthetic and | |
spatial. | |
3. Besides, this new media should also be dynamic because to understand a system it's not | |
enough to see one static representation or a variable at a time. You should see the system | |
running to be able to fully understand its dynamics. | |
In this thesis we argue that we should revisit our traditional programming paradigms to | |
address these issues. | |
We further propose a number of research challenges: | |
1. Bring programmers inmerse into the domain model and avoid any kind of distractions by | |
working permanently within a "pure" conceptual modeling environment. This conceptual | |
environment must provide an holistic view of a software system, including all necessary | |
aspects of function (behaviour), interaction (system integrations and user interactions) and data | |
(structure). | |
2. Build a domain-aware runtime environment --a kind of domain-aware virtual machine-- able | |
to interpret any valid conceptual model. This runtime environment will enable a very fast | |
feedback loop based on our work-in-progress models. | |
3. Experiment with new media for working with dynamic and powerful representations to think | |
and learn about our software systems. | |
References | |
========== | |
[1] The Death of Object-Oriented Programming. Oscar Nierstrasz. Software Composition Group, University of Bern, Switzerland. | |
[2] Conceptual-Model Programming: A Manifesto. David W. Embley, Stephen W. Liddle, and Oscar Pastor. | |
[3] The Humane Representation of Thought. Bret Victor. http://worrydream.com/TheHumaneRepresentationOfThought/note.html | |
[4] Media for Thinking the Unthinkable. Bret Victor. http://worrydream.com/MediaForThinkingTheUnthinkable/ | |
[5] Patterns of Software: Tales from the Software Community. Richard P. Gabriel. | |
[6] Object Thinking. David West. | |
[7] Domain-Driven Design:Tackling Complexity in the Heart of Software. Eric Evans. | |
[8] Implementing Domain-Driven Design. Vernon Vaughn. | |
[9] Domain-Driven Design Reference: Definitions and Pattern Summaries. Eric Evans. | |
[10] The Nature of Software Development. Ron Jeffries. | |
[11] The CRC Card Book. David Bellin and Susan Suchman. | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment