Creating great systems with the help of Olympic athletes, agile and pretotypes

When Alan Kay first coined the term object orientation he saw an object as an independent computer and a system as a network of interconnected objects. A lot of water has passed under the bridge since then and now what most people think of when talking about object orientation, is in the words of the father of MVC class-orientation. The distinction between object orientation and class orientation being that objects as Kay envisioned them, a are dynamic runtime entities, to the extent that they from a type theoretic perspective might change their type during execution. Class orientation is a limited view of the system and makes it hard to impossible to reason about runtime behavior by looking at the code.

A system is only as good as the end users value it and a common obstacle in software development is the communication gap between end users and developers. End users have a mental model of the system and as human beings we are better at using tools if the underlying model of the world resembles our own. But most contemporary architectural schools based in the class oriented world violate the users mental model, e.g. an operation that the user sees as a whole might be distributed across several classes, where each class describes an entity that the user knows but also operations that can be performed on that entity, which to the user might very well be external to the entity.

Evolution has equipped us with the ability to learn by example and we are programmed to base our learnings on previous learnings. That is why it is not difficult to learn English as a mother tongue but inherently so if your mother tongue is French and the real important fact is that it doesn't really matter how long you've lived in England, if your mother tongue is French most people will be able to tell until the day you die. Learning a computer system is the same. If the model used in the system fits your view of the domain you will be better at using the system and for complex systems that advantage does not go away over time. This all comes back to the communication gap. If we are capable of capturing the mental model of the end users we reduce the communication gap and might even be able to talk more successfully to end users about architecture if not code artifacts.

When coaching Olympic athletes or business professionals you learn among other things how to illicit the underlying motivations, hopes and dreams of the individual and by that help the individual to figure out their own needs and through the process commit to a plan of actions to reach the dream.When you help them formulate the dream, you will help them formulate goals on the way to the dream. If the dream is participation at the Olympics you might have a goal of qualifying for the world championship the preceding season and to learn a specific technical detail prior to participation in the worlds . This process is repeated until you have set first goals to accomplish this year, this month and in the end you have a (set) of goals for today. In this way you as a coach can work together with the athlete to find the path of least resistance that leads to the dream. This process has been researched extensively. The sole factor that sets all high achievers a part, is dedication to refine goals and subgoals to the extent that while practicing, new goals for the next drill might be based the execution of the current drill.This is also referred to as dedicated practice and has been shown to be the important factor in a variety of fields such as sports, music, chess and business.

If we view the development of a complete system as reaching the dream we could use the same approach. We start by formulating a dream for our software. It should be formulated in functional terms. Several goals and dreams might be fulfilled with the same piece of software. E.g. a word processor might be used to write a book or love letter but we start with one, just like the athlete we start with the one we believe has the highest value. We divide the dream into goals which we might call milestones or major releases and each of these into minor releases and we continue till we reach sprints and tasks. However doing this top down and asking the right questions, we capture the user mental model in the process and if we ask smart questions we not only capture the requirements and the mental model, we also find the path of least resistance to the most elegant solution. We will for each goal end up with a distinct system (or object in the Alan kay model) and each of these systems will be a distinct artifact in code as well as in documentation and be part of the user mental model.

The resulting structure of the documentation when following this approach is a network of interconnected goals, and if we view each goal as a distinct system then said network is very much like Alan Kay's view of an object oriented system.

In the spirit of Lean, we should strive to only produce what we need and since each of these systems makes for a pretotyping candidate it would be a perfectly valid approach to treat the entire development life cycle as incrementally building new pretotypes.

What proponents such as the farther of MVC, Trygve Reenskauge or one of the founders of the software patterns discipline James "Cope" Coplien calls full OO are extremely good at expressing this kind of systems. DDD would lead us to divide the system based on the entities of the end user mental model and attach the parts of the system operation that are related to each entity to the same class. That destroys the ability to reason about the code unless you are able to construct the call graph mentally. If parts of the system are polymorphic, trying to do so will be futile. Full OO enables us to build complex systems where each complete system operation is located in the same code entity while still dividing the domain into the entities of the real world as they are represented in the end user mental model. This results in the ability to reason about runtime behavior of a specific and complete system operation and since the code entity will be directly related to a specific part of the requirements, it is possible to review these in union and possible to review the correctness together with the end users.

The talk will go through the steps in the process of creating great systems and will describe the design and requirements process along with giving examples of how to structure and implement the system based on the DCI paradigm. The concept of pretotyping will also be touched upon but the talk is not as such a talk on pretotyping.

The delegates can expect to be able to comfortably use the design approach when the talk is over and to have a sufficient understanding of the DCI to be able to try it out themselves.