In the previous article we talked about the reasons we call ∞OS an open source operating system. The analogy from the software development world allows us to make a shift from the abstract into the pragmatic in a very efficient manner. We treat any practice as a set of patterns, which can be implemented on behavioral level and applied in real life. Such approach makes ∞OS compatible with other operating systems: be it rules of ethics and morals, religion, meditation, yoga, organizational frameworks (like Holocracy), etc. It also brings in an extra degree of openness and interoperability. If you think of any practice as an open source software framework then it can be customized, upgraded, installed and deactivated (in case it doesn’t fit or if there’s a better option available). It also makes it much easier to combine different approaches and to create your own operating systems, which resonate with your set of values and needs.
The most impressive advantage of the operating system analogy is the huge range of practices that it brings in from the world of software development. These techniques offer a very effective way of experimenting and prototyping the new patterns of behavior and exploring oneself.
∞OS integrates these practices into its processes and offers concrete physical exercises, which offer first-hand physical experience of these practices for the participants making it much easier to understand how they work and to implement them on unconscious level.
Agile Development & Iterative Updates
Agile one of the main approaches used today in software development but also in business, especially in lean startups. The main idea is to work in short iterations and to deliver working prototypes on a regular basis using the feedback from the environment to adjust to the changing needs. One of the tenets of this approach is “make it work, make it fast, make it right”, taking the focus off perfectionism, bringing a more pragmatic perspective that takes objectives and live feedback into account. One could say that Agile approach is better suited for uncertainty. The complex world we live in makes it very hard to predict what’s going to happen to to make the best possible decision — reality is changing too fast. However, it is still possible to come up with a workable solution that can be implemented quickly. Therefore, Agile can yield great results especially on the tactical level, when one needs to be adaptive and to act fast.
Most ∞OS procedures are based on Agile approach. When we train, for example, we work on certain principles letting the participants explore the different ways of bringing these principles to life and making them work. The exercises take place through short iterations also with changing partners and active feedback from all the participants, so they can adjust to each other’s bodies and movement. ∞OS itself as a practice is also agile in the way that it’s always evolving and changing its approach. We release new “updates” every few weeks and constantly adjust our teaching methods. Below you can find a sample ∞OS procedure, which demonstrates agile approach both in how the exercise is made and what it actually practices:
There are different ways to write software, among them is object-oriented approach and functional programming. Object-oriented approach works with objects and states, which are being recorded, stored, and transformed during the program. In order to do something you need to first get the state of the system and then apply certain operations to it to transform that state into the new one.
In functional programming you are separating the program into the different behaviors that it performs (functional modules). It’s not anymore about the states but more about what needs to be done. Once the objective is identified, the function can be created. The more abstracted and reusable this function is, the easier it is to apply it for other similar situations and to make it universally available in general scope in any context.
Therefore, whereas the object-oriented approach tends to break problems into groupings of “nouns,” or objects, a functional approach breaks the same problem into groupings of “verbs,” or functions.
We apply a similar — functional — approach to ∞OS practice, integrating it not only on the level of what we teach but also how.
Consider one of the ∞OS procedures shown below. The idea is to redirect the incoming impulse. We don’t care so much what the incoming state of this impulse is or what exactly we want it to become. Rather, we focus on how we perform the action, the function of what we want to do and what we want to achieve the moment it happens:
When we asked on Quora what practices from the world of software development seem to be the most useful in other contexts and everyday life many people pointed towards Unit Testing. It is important to note that Unit Testing is different from Integration Testing. In Integration Testing the different modules of software are tested as a group to see how they interact and if there are any errors arising from this interaction. In Unit Testing the program is separated into the smallest functional units that are tested independently from each other. If they rely on the other units (e.g. a database) then a temporary abstraction layer is created for that particular test so that it doesn’t have to rely on dependencies and so that it can get tested on its own.
For example, the Oscillatory Feedback Procedure, which is a good example of a dynamic prolonged confrontation, relies on several functions and principles that should work properly in order for the procedure to be effective. In order to ensure that this procedure works as intended it is important to test the smaller functional units that it consists of (integrity, tensivity, fluidity, adaptivity) using very simple exercises as exemplified below:
And only then one can move on to perform integrative testing on the procedure at large:
When everything happens at the same time, we are forced to think of processes as co-isolated multiplicities that interact on the global level and yet retain their essence. It then becomes less about the narrative and more about the relations of one functionality towards the other. There is no more chronology of events, rather, there are happenings that consist of temporary synchronizations across various modules to fulfil a specific task (usually triggered by users). The narrative then has multiple possible flows, which may freely relate to one another depending on the context, intention and circumstances.
Branch by Abstraction
This is a technique to make large-scale change without disrupting the operation. A layer of abstraction is created between the part of the software that will not be changed (e.g. the interface) and the part that is to be changed (e.g. moving to a new database). We then start to gradually implement the changes, swapping over the functionality from the old part to the new part via the abstraction layer, so operations are not disrupted.
Version Control and A/B Experiments
Almost any software development project makes use of version control. Each time you make a change you create a new “branch”, which is a thread of the main project. Once the change is made, tested, and implemented you can always merge it back to the main project. In case something is wrong or the change has a negative impact on the system, it is always possible to “roll-back” to the previous version (“commit”). Read more about this approach in our post on A/B Experiments and Version Control for Learning.