The explore/exploit strategy is an iterative approach to systems engineering and team formation.
It starts out with an exploration phase and scales both system and team size during the exploitation phase.
Later on, the strategy is repeated for either product improvements, disruptive changes, or new projects and teams.
A general introduction to the explore/exploit strategy is described in Brian Christian's and Tom Griffiths' book named "Algorithms to Live By".
The advice divides the time you spend on tasks into an exploration and an exploitation phase.
Exploration is gathering knowledge, and exploitation is using the knowledge.
The idea is to explore things when you will have time to use the resulting knowledge, and exploit it when your are ready to cash in.
Another example of the explore/exploit startegy is given in Richard Hamming's book "Learning to Learn".
He concluded one should have a plan to first explore things in a research phase, and then exploit that knowledge to build something.
The exploration phase is best described by scientific research:
In science, if you know what you are doing, you should not be doing it.
While the exploitation phase maps well to engineering:
In engineering, if you do not know what you are doing, you should not be doing it.
Of course, both exploration and exploitation as well as science and engineering are tightly coupled with each other in an iterative process to make progress.
Change does not mean progress, but progress requires change.
Progress is achieved then by repeating the explore/exploit cycle over and over again with the results of an exploitation phase fueling new exploration phases.
From time to time, this repeating process ends up in disruption and disruptive technology, a terminology defined by Clayton Christensen in his book "The Innovator's Dilemma".
The explore/exploit startegy helps to understand and boost various aspects in both software engineering and team formation.
Explore
The exploration phase must be started by a small, motivated and joyful team with common sense that focuses on the hardest problems first.
Louis Pasteur's remark, "Luck favors the prepared mind", perfectly summarizes the purpose of this phase.
It both admits there is an element of luck and yet claims to a great extent it is up to you.
You prepare yourself and your team to succeed or not.
Good advice for how to master the exploration phase can be found in Frederick Brooks' book on "The Design of Design".
A quick summary can be found in one of my older blog posts about "Frederick Brooks on Software Design".
The few designers who do the exploration phase, build up a plan in mind for later execution.
According to Brooks, the outcome of the exploration should be a plan with conceptual integrity - unity, economy, clarity, delight.
The plan is partly implemented during the exploration phase to learn fast from mistakes and other aspects of the design.
Another, bigger part of the plan is done during the exploitation phase while the team grows in size.
An important fact, according to both Richard Hamming and Clayton Christensen, is that most of the great innovations come from outside the field, not from the insiders or experts.
Probably because experts tend to neglect or shorten the exploration phase and immediately rush into the exploitation phase.
Another remark from Richard Hamming is that some, not all experts rely too much on their own knowledge bubble:
Working with one's door closed lets you get more work done per year than if you had an open door, but I have observed repeatedly that later those with closed doors,
while working just as hard as others, seem to work on slightly the wrong problems, while those who have let their door stay open got less work done but tend to work
on the right problem! I suspect the open mind leads to the open door, and the open door tends to lead to the open mind.
A further good source of advice about the exploration phase is Richard Hamming's talk about "You and your research":
If you prefer text, have a look on Hamming's paper on "You and your research".
Exploit
The interaction with harsh reality tends to push you into significant discoveries which otherwise you would never have thought about while doing pure research in a vacuum of your private interests.
That means it is very important to start exploiting the knowledge garthered during exploration alongside scaling the team, not too early and not too late.
The most important step during exploitation is team formation as well as building a common mindset and language within your team.
Therefore, defining a few basic architectural building blocks during the design phase and documenting them with a software development kit and examples is crucial.
While scaling your team always assure to build up many experts, not just a single or few knowledge towers, as explained by Richard Sheridan in his book "Joy, Inc.".
Otherwise such superstars will hoard knowledge without sharing it, and ultimatively wreck the overall team results and morale.
Keeping high quality results while expanding the team requires a balanced team without a central superstar, a team which truly and authentically cares about things.
Also see one of my older blog posts about the Characteristics of an efficient engineering team.
The leader of such a team is best when people barely know he/she exists. As Laozi said, that when the work is done, the aim fulfilled, they will say: we did it ourselves.
Keep in mind that there is never time to do the job right, but there is always time to fix it later.
As mentioned by Alan Kay: "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be."
So as long as the overall system design has conceptual integrity, you and your team will have plenty of room for future improvements and refactorings, hopefully without changing public interfaces.
Repeat/Iterate
Great designers grow with their challenges. They need a constant flow of exciting challenges for mastery.
Therefore, you will repeat the explore/exploit startegy over and over again for product improvements or new projects.
Success means you and your team will get better problems to work on.
But what you did to become successful is likely to be counter-productive when applied at a later date.
For that reason you have to iterate to a new exploration phase with some of your team not to get stuck in exploitation.
Being an expert all the time is not what you should aim for. Be a hungry and foolish beginner from time to time.
The automotive industry is undergoing substantial changes as new technologies for connected cars, autonomous vehicles and electric vehicles are creating new customer expectations.
In this webinar, Dominik Obermaier (CTO of HiveMQ) and me discuss four key paradigm changes that need to happen for the automotive industry to remain competitive and deliver on the customer experience of the future.
Software Platforms and Software Development Kits
Publish/Subscribe Messaging on both Edge and Cloud Side
Domain Modelling
Pragmatic Software Development Processes
In this video you will learn how modern software technologies like publish/subscribe messaging using MQTT and Kafka, domain modeling, as well as edge and cloud computing will accelerate time to market for new automotive features and improve customer experience.
Saša Jurić talks about the Erlang runtime, the BEAM virtual machine.
Since years I planned to write a post about "Why can Erlang have this 'let it crash' methodology and all others can't?".
Now, Saša Jurić shows exactly that along with other runtime features of the BEAM VM is his talk about the Soul of Erlang and Elixir.
His talk perfectly extends my last post about What's Next for Our Programming Languages and Operating Systems? and gives a glimpse on the future.
Joe Duffy (previous Microsoft Director of Engineering for Languages and Compilers), Richard Feldman (Elm Software Engineer), Brian Goetz (Java Language Architect at Oracle) and Sylvan Clebsch (Designer of the Pony Programming Language) discuss the future of programming languages.
02:49 Brian Goetz: When I am working on a programming problem and not making progress the root cause usually is that I am not thinking clearly about the data flows. Once you get the data flows right then the code pretty much writes itself.
28:29 Richard Feldman: Immutability rules out a lot of concurrency related problems. Will programmers adapt and use different programming paradigms where these problems (concurrency, data-safety, etc.) cannot happen anymore?
39:15 Brian Goetz: There is the programming language you program in. And then there is the runtime which really is the important part. That's where all your deployment, debuggability, monitorability, serviceability comes from. Developers (who are focused on code) often think the surface language is the important part. But in a lot of ways the runtimes matter way more than programming languages do.
46:53 Sylvan Clebsch: The Actor model programming paradigm makes OOP vs. FP discussions unnecessary.
49:22 Sylvan Clebsch: The programming language is a UI to the runtime.
My Comments
I think that software architects and engineers focus way too much on code instead of data flows. Understanding the data flows in a system and arranging them efficiently usually points you to the best and simplest architectures.
Brian Goetz definition of programming language runtimes and Sylvan Clebsch comment that we should regard programming languages just as user interfaces to their runtime systems is so true. I would even say that most languages I like, I do that mostly because of their runtime system and not so much for the language itself.
The Erlang runtime system (programming language) provides me a really nice Actor model paradigm I love to program in, and perfect abstractions how to build reliable, fault-tolerant distributed systems.
The Android framework to me is a superb runtime on the Java VM that provides much more fun and simplicity for writing correct programs than the standard Java runtime system abstractions. Their Actor model implementation (Handler/Looper/MessageQueue) is far more easy and fun to work with than Java's pure Thread and Executor stuff. Having callbacks run in the application thread (actor) without introducing concurrency issues is just great and must be the norm!
The main reason for building the Mindroid frameworks/runtimes for Java, C++ and embedded C++ is due to the fact that the standard Java and C++ runtimes do not provide neat, slim and consistent application models (Erlang guys would say behaviors) to work with. Mindroid provides a consistent way to develop Java, C++ and embedded C++ applications using the Actor model design pattern. It bridges language boundaries and helps in building correct, fault-tolerant (distributed) systems.
Both operating systems and/or programming systems (languages) can provide runtimes that are fun to work with. Besides Erlang, I really loved to work with the QNX operating system since it provides nice, yet easy to understand, abstractions for building modular (distributed) systems using inter-process communication (CSP-style IPC) and resource managers (kind of an Actor model).
Runtimes standardize ways of doing things and behaviors so that not everybody needs to reinvent the wheel. I think nobody ever tried to implement her/his own Actor model implementation or distribution transparency mechanism on top of Erlang or Elixir.
Operating systems and language runtimes should align on basic building blocks like fast message passing as well as inexpensive processes (for isolation) and fast process switching. Furthermore, both should have first-class support for distributed systems including distribution transparency, supervision trees and (topic-based) publish/subscribe messaging.
Schnelles Denken, langsames Denken (englischer Originaltitel: Thinking, Fast and Slow) ist ein Buch von Daniel Kahneman, das seine oft gemeinsam mit Amos Tversky durchgeführten Forschungen aus mehreren Jahrzehnten zusammenfasst.
Die zentrale These ist die Unterscheidung zwischen zwei Arten des Denkens: Das schnelle, instinktive und emotionale System 1 und das langsamere, Dinge durchdenkende und logischere System 2. Das Buch schildert kognitive Verzerrungen im Denken von System 1, und bietet dabei einen breiten Querschnitt von Forschungsergebnissen der sogenannten Heuristics-and-biases-Schule, die von Tversky und Kahneman in den 1970er Jahren begründet wurde. [Quelle: Wikipedia "Schnelles Denken, langsames Denken" vom 9. Juli 2017].
Die Psychologie zählt für mich neben der Biologie und der Informatik zu den spannendsten Wissenschaften. Als Informatiker finde ich es sehr beeindruckend, dass sich die Psychologie der Abstraktion bedient, um das Denken mittels zweier Systeme zu beschreiben. Dieser Beitrag soll mir als Zusammenfassung und Nachschlagewerk von Daniel Kahneman's Buch dienen; einem Buch das jeder mehrmals lesen sollte.
System 1
Schnell, automatisch, immer aktiv, emotional, stereotypisierend, unbewusst.
Das assoziative Gedächtnis, der Kern von System 1, konstruiert fortwährend eine kohärente Interpretation dessen, was zu jedem beliebigen Zeitpunkt in unserer Welt geschieht.
System 1 ist nicht für statistisches Denken ausgelegt, da wir tendenziell unser Wissen über die Welt überschätzen und wir unterschätzen welche Rolle der Zufall bei Ereignissen spielt.
System 1 ist so gestaltet, dass es aus dürftigen Informationen automatisch weitreichende Schlussfolgerungen zieht - es ist aber nicht imstande, zu ermessen, wir groß die Sprünge sind, die es beim Folgern macht. Wegen der WYSIATI-Regel zählen nur die verfügbaren Informationen.
System 1 ist leichtgläubig und neigt dazu Aussagen für wahr zu halten.
System 2
Langsam, anstrengend, selten aktiv (faul), logisch, berechnend, bewusst.
Zielgerichtetes, strukturiertes und konzentriertes Denken.
Eine der Hauptfunktionen von System 2 besteht darin, von System 1 "vorgeschlagene" Gedanken und Handlungen zu überwachen und zu kontrollieren; einigen davon erlaubt es, sich direkt im Verhalten auszudrücken, während es andere unterdrückt oder modifiziert.
Die Arbeitsteilung zwischen System 1 und System 2 ist höchsteffizient, da sie Aufwände minimiert und die Leistung optimiert.
Oftmals folgt das faule System 2 den Vorschlägen von System 1, was unser Denken anfällig für systhematische Fehler macht.
System 2 wird durch kognitive Beanspruchung mobilisiert.
System 2 ist dafür zuständig Aussagen anzuzweifeln, aber System 2 ist manchmal beschäftigt und oft faul.
Flow bezeichnet das als beglückend erlebte Gefühl eines mentalen Zustandes völliger Vertiefung (Konzentration) und restlosen Aufgehens in einer Tätigkeit.
Priming Effekt bezeichnet eine Beeinflussung einer Handlung durch eine Vorstellung.
Kognitive Leichtigkeit beschreibt ein Konzept, nach welchem entschieden wird, ob die Aufmerksamkeit neu ausgerichtet werden muss (Aktivierung von System 2) oder ob den Antworten von System 1 geglaubt werden kann.
Halo-Effekt: Unter dem Effekt wird die Tendenz verstanden, faktisch unabhängige oder nur mäßig korrelierende Eigenschaften von Personen oder Sachen fälschlicherweise als zusammenhängend wahrzunehmen.
Kognitive Verzerrung ist ein kognitionspsychologischer Sammelbegriff für systematische fehlerhafte Neigungen beim Wahrnehmen, Erinnern, Denken und Urteilen.
WYSIATI - What You See Is All There Is: Voreilige Schlussfolgerungen aufgrund unvollständiger oder falscher Informationen.
Ankereffekt ist ein Begriff aus der Kognitionspsychologie für die Tatsache, dass Menschen bei bewusst gewählten Zahlenwerten von momentan vorhandenen Umgebungsinformationen beeinflusst werden, ohne dass ihnen dieser Einfluss bewusst wird.
Basisrate: Die Basisratenvernachlässigung, d. h. die Überschätzung der bedingten Wahrscheinlichkeit von Ereignissen mit niedriger Basisrate, erklären Kahneman und Tversky mit der Anwendung der Repräsentativitätsheuristik. Wahrscheinlichkeitsurteile sollten sich daher an der Basisrate orientieren.
Die Bayessche Regel gibt genau an, wie bestehende Überzeugungen (Basisraten) mit der Aussagekraft der Erkenntnisse - dem Ausmaß, in dem sie die Hypothese gegenüber der Alternative begünstigen - kombiniert werden sollten. Somit handelt es sich um die Verankerung eines Urteils über die Wahrscheinlichkeit eines Ereignisses in einer plausiblen Basisrate.
Regression zum Mittelwert ist ein Begriff der Statistik; er bezeichnet das Phänomen, dass nach einem extrem ausgefallenen Messwert die nachfolgende Messung wieder näher am Durchschnitt liegt, falls der Zufall einen Einfluss auf die Messgröße hat.
Selbstüberschätzung
Die Kompetenzillusion ist nicht nur ein individueller Urteilsfehler; sie ist tief in der Kultur der Wirtschaft verwurzelt.
Checklisten und einfache Regeln: Einfache statistische Regeln sind meistens intuitiven Urteilen überlegen. (Paul Meehl)
Intuition ist nicht mehr und nicht weniger als Wiedererkennen.
Voraussetzungen für Expertise sind eine hinreichend regelmäßige Umgebung um vorhersagbar zu sein sowie eine Gelegenheit diese Regelmäßigkeit durch langjährige Übung zu erlernen. Wenn es keine stabilen Regelmäßigkeiten in der Umgebung gibt, kann man der Intuition nicht vertrauen.
Entscheidungen
Der Planungsfehlschluss ist die Tendenz von Leuten und Organisationen, zu unterschätzen, wie viel Zeit sie zur Vollendung einer Aufgabe benötigen. Wir konzentrieren uns auf unser Zeil, verankern uns in unserem Plan und vernachlässigen relevante Basisraten.
Prä-mortem-Methode überwindet übermäßigen Optimismus indem sie Zweifel zulässt und nach möglichen nicht betrachteten Gefahren sucht.
Verlustaversion bezeichnet in der Psychologie und Ökonomie die Tendenz, Verluste höher zu gewichten als Gewinne. Die Verlustaversion ist ein Bestandteil der Prospect Theory (deutsch: Neue Erwartungstheorie), die 1979 von Kahneman und Tversky aufgestellt wurde.
Die Außensicht ist ein sehr wichtiges Monitoring-Instrument, da die Innensicht zum WYSIATI-Effekt neigt.
Framing-Effekt bezeichnet die Tendenz, dass unterschiedliche Formulierungen einer Botschaft – bei gleichem Inhalt – das Verhalten des Empfängers unterschiedlich beeinflussen.
Zwei Selbste
Erlebendes Selbst vs. erinnerndes Selbst: Ich bin mein erinnerndes Selbst, und das erlebende Selbst, das mein Leben lebt, ist für mich wie ein Fremder.
Gedankenexperiment
Möglicherweise ist die Idee der Abstraktion unseres Denkens mittels System 1 und System 2 ein ideales Design bzw. eine vielversprechende Architektur für KI-Systeme wie etwa autonome Roboterautos.
Software design and architecture always has been my foremost interest and fun part in computer science. Frederick Brooks' book "The Design of Design" summarizes a lot of useful facts and topics all system designers will learn about sooner or later. This post contains some few excerpts from his excellent book.
The Design Question
Design is to plan in mind for later execution.
For most human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, "working out" are essential disciplines for the theoretician.
Great designers have conceptual integrity - unity, economy, clarity, delight.
Frederick Brooks in his classic book "The Mythical Man-Month" about conceptual integrity:
"I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.""Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds."
Conceptual integrity does not emerge from democracy. The result of a democratic approach is a compromise that does not meet the needs of any single person or the customer.
"The separation of architectural effort from implementation is a very powerful way of getting conceptual integrity on very large projects."Design Models
The theory of design is the general theory of search through large combinatorial spaces of possibilities.
Sometimes the problem is to discover what the problem is.
Goal iteration must be considered an inherent part of the design process.
The most potent reason to study design history is to learn what doesn't work, any why.
Ask yourself: Am I doing the right thing? or am I just doing the thing right?
Study failure examples even more carefully than you study successes.
Any attempt to formulate all possible requirements at the start of a project will fail and would cause considerable delays.
Collaboration in Design
Most great works have been made by one mind. The exceptions have been made by two minds.
Great designs often arise in physical isolation, small teams, intense concentration, and leadership by one mind.
Great designers most have a clear vision of and for the system and must really care about its conceptual integrity.
Clean interfaces make a big difference in the error rate of the design.
Clean interfaces give multiple designers each the joy of ownership, of the privilege of signing a piece of work. They also facilitate sequential ownership, as small components flow together into larger subsystems.
The telephone provides an even bigger collaboration breakthrough than email.
Constraints are Friends
A general-purpose product is harder to design well than a special-purpose product.
Constrains shrink the search space of possibilities.
The hardest part of designing is deciding exactly what to design.
Any design process begins with the designer elaborating and particularizing the objectives and constraints. The first task is to narrow the design space.
Esthetics and Style in Design
Style is the dress of thought, and a well-dresses thought, like a well-dressed man, appears to great advantage.
Definition of style: Those features of literary composition that belong to form or expression rather than to the substance of the thought or matter expressed.
Computer design clearly must place a high value on parsimony, the use of few elements (building blocks).
Consistency is reinforcing and self-teaching, because it confirms and encourages our expectations.
Uniform style aids comprehensibility of a design.
Great Design and Great Designers
Good design is top-down.
Great designers, even the most iconoclastic, rarely start from scratch - they build on the rich inheritance from their predecessors. This is why you must know about design (computer science) history.
Great designs come from great designers, not from great design processes.
Very good programmers are ten times as productive as poor ones.
Give the system architect full authority over the design.
Every man who rises above the common level has received two educations: the first from his teachers; the second, more personal and important, from himself.
Design productivity requires flow, an uninterrupted mental state of high creativity and concentration.
The Mythical Man-Month
Lean, sparse, fast programs are almost always the result of strategic breakthrough, rather than tactical cleverness.
Often such breakthrough will be a new algorithm.
More often, the breakthrough will come from redoing the representation of the data or tables. Representation is the essence of programming.
You can never plan the future by the past.
Be careful how you fix what you don't understand.
One addition from my side
Great designers grow with their challenges. They need a constant flow of exciting challenges for mastery.
Alan Kay is a computer scientist and pioneer who was part of the Xerox PARC team of about 30 researchers that developed many of the key concepts of today's hardware and software technologies.
This post contains some famous keynotes and other talks by Alan Kay including quotes and comments.
05:00 We must know about the past (the pioneers of computing) to invent the future.
13:53 We cannot invent the future by using vendor computer hardware and software.
34:29 Knowledge almost always trumps IQ. A change in perspective is worth a lot of IQ points.
36:31 Clever hacks don't scale well and worse keep broken things around for too long.
39:45 Learning a new idea requires almost as much creativity as the original invention.
49:27 Wayne Gretzsky theory of hockey: Why are you a so much better hockey player than everybody else? Everybody else just goes where the puck is, I go where it is going to be.
1:01:08 All understanding begins with our not accepting the world as it appears (Susan Sontag).
1:02:17 Brains were designed for survival and coping, not for great inventions. Science is a way to get around that limitation.
Programming and Scaling
06:50 The biggest problem we have as human beings is that we confuse our beliefs with reality.
08:21 Make-and-fix paradigm: Nowadays, computing is mostly tinkering and not engineering.
18:03 The internet is one of the few human artifacts that behaves like a living organism.
25:11 Smalltalk (OO) mistake: Objects are too small! The scale jump from molecules to a living organism is incredible compared the scale jump when trying to make objects. Idea: Make much more capable universal objects and try to build things out of that.
33:11 Most people can only experience the present in terms of the past. (Marshall McLuhan)
30:05 Our strain of humanity is on the planet for about 192.000 years (tracing mother's mitochondrial DNA) and we only invented science 400 years ago. That's why IQ does not count that much.
37:00 Past, Present, Future: The past is enormous!
42:43 Computing is mostly tinkering at this time, there's not much engineering, math, or science.
Is it really "Complex"? Or did we just make it "Complicated"?
1:13:10 Next generation publish/subscribe systems in UI/UX design: Widgets communicating by a publish/subscribe methodology to announcements of events.
1:38:00 Computer science is the science of processes. It is about thinking, reasoning, and talking of processes as well as representing, constructing and debugging them both in hardware and software.
@ SAP
12:47 Our perception of the future is mostly just a little increment on the present.
13:01 Innovation is just taking an idea or invention that already exists into the marketplace.
19:19 Problem finding is much harder than problem solving in order to make progress.
21:14 You are doing research only so long as you can change your mind. Making decisions consolidates one's mind.
21:53 Most software in the world is absolutely not designed!
25:01 Thinking is not remembering!
37:50 Big data: What we need is not big data but big meaning (including descriptions for processes, relationships and constraints).
40:33 Building with gears does not scale (< 1000 gears)! Biology scales!
42:58 The internet is one of the few human artifacts that behaves like a living organism.
44:19 Learning how to code is like the last thing you wonna learn about computing. Computing is about systems, not about algorithms, not about if-statements; it is about powerful ideas that are made into descriptions computers can interpret.
56:55 How do you learn how to bike? Using a low bike without pedals. Bicycle training wheels are actually anti-learning! Lessons learned: Software called "user-friendly" very often isn't.
Power of Simplicity
10:01 You get simplicity by finding a slightly more sophisticated building block to build your theories out of. The inability to fix the existing building blocks is one of the largest problems that computing has today. The building blocks (abstractions) help in putting stuff into the right context.
23:53 You need to solve the context, not just a problem!
24:14 Finding out about the real problem is the big deal and it may be much harder than solving the problem itself.
32:39 What is your company's 10 year plan? Umm...
49:27 Wayne Gretzsky: A good hockey player is going to where the puck is, and a great hockey player is going to where the puck is going to be.
50:11 "Better" and "Perfect" are the two enemies of "What Is Actually Needed".
The Future Doesn't Have to Be Incremental
21:55 Human universals by anthropologist Donald Brown (e.g. coping, social, language, culture, fantasies, stories, news, art, etc.). Most popular software products work as technological amplifiers for at least one such human universal.
28:15 Linux is a budget of bad ideas.
29:12 Real inventions: E.g. writing and reading, abstract math, model-based science, democracy, equal rights, slow deep thinking, etc.
30:48 Isaac Newton changed the way of how people think.
35:23 Wayne Gretzsky: You miss 100% of the shots you don't take.
The computer revolution hasn't happened yet
16:45 OOP architecture: As complexity starts becoming more and more important architecture is always going to dominate material.
24:11 It only takes about 50 cell divisions (iterations) to make a baby.
35:11 In contrast to biology computers are slow, small and stupid.
37:01 Cell membrane acts like a pattern matcher and it keeps most of the things out as much as it keeps certain things in.
The Best Way to Predict the Future is to Invent It
11:39 We all have a duty to the next generation, whether or not we have children!
13:26 Our brain is mostly set up for reacting (System 1) and it tries to avoid real thinking (System 2).
27:31 "We must ensure that human wisdom exceeds human power" (Vi Hart)
My view is that you want to avoid shared data structures as much as possible. Systems should be composed of smallish modules that completely hide their internal data structures from everyone else. They should have well-defined ‘thin’ interfaces that other modules can call to get work done. That’s what object-oriented programming is all about – hiding information – not sharing it. I think that hiding information (a la Dave Parnas) is a good idea. It means you can change the data structures, algorithms, and design of any module at will without affecting system correctness, as long as you keep the interface unchanged. Every course on software engineering teaches this. In effect, Linus is saying the past 20 years of work on object-oriented programming is misguided. I don’t buy that.
Once you have decided to have each module keep its grubby little paws off other modules' data structures, the next logical step is to put each one in a different address space to have the MMU hardware enforce this rule. When applied to an operating system, you get a microkernel and a collection of user-mode processes communicating using messages and well-defined interfaces and protocols. Makes for a much cleaner and more maintainable design. Naturally, Linus reasons from his experience with a monolithic kernel and has arguably been less involved in microkernels or distributed systems. My own experience is based on designing, implementing, and releasing multiple such operating systems myself. This gives us different perspectives about what is hard and what is not.
During the last years me and my team built various automotive software systems in the connected car domain as well as in the body domain.
Before that, we built Android-based infotainment systems, mobile internet routers and some kind of wireless display like Miracast.
Over time, our work became highly inspired by two software platforms and their characteristics: Erlang and Android.
Erlang's influence came mostly from its reliability characteristics and its shared-nothing methodology.
Android provides a modular, component-based application framework including a software development kit and documentation which we wanted to have for all kinds of automotive software systems as well.
This led to the developement of the Mindroid application frameworks.
What is Mindroid?
In short, Mindroid is a component-based application framework similar to Google's Android, including a software development kit and documentation.
It builds upon the Actor model as core system architecture building block and provides an event-based programming paradigm.
Currently, there are three variants of Mindroid.
Mindroid.cpp targets native platforms, like Linux or QNX Neutrino RTOS
Mindroid.ecpp targets deeply embedded systems without dynamic memory management, like AUTOSAR OS, CMSIS RTOS or even bare metal
One of Mindroid's main goals is to provide a slim platform to develop highly reliable (distributed) software systems. Other goals and their prerequisites are:
Modularity: Components with clear interfaces, threading and dependencies
Reuse: Set of reusable components across projects and platforms
SDK: Sustainable, public APIs crafted by an API first design approach (Finding good abstractions and truly care about naming things)
Reliability, testability and refactorings: No shared state between components
Software quality highly benefits from Actor model design approach
No complex critical sections
Callbacks run in right thread contexts
Low energy, CPU time and memory requirements
Logging (No long-lasting debugging sessions)
Slim platform: Simplicity is prerequisite for reliability
Scalability: Distributed systems running multiple Mindroid instances on different nodes
Mindroid relies on the Erlang-style actor process model to achieve that goals. The core Actor model is mainly based on the Android Thread, Looper, Message, MessageQueue, Handler and Binder classes. Together with the Process class Mindroid implements deployable components and component isolation comparable to Erlang-style process isolation.
The component isolation assures that there is no shared state across component boundaries. This is done by exchanging only POD types a.k.a. plain old data structures and component interfaces (actor endpoints) on component interface level. Using such component interfaces one can access further components.
Furthermore, each component clearly defines its own threading behavior within the hosting process to achieve true component isolation regarding data (no shared state) and the runtime environment (process and actor).
Slide 5 below illustrates the Erlang-style actor process model using a CarFinder component that relies on a LocationManager for location updates.
For future, we plan to implement Erlang-style distribution transparency for services and service discovery.
And we would love to have a Rust variant of Mindroid.
An efficient engineering team offers a fun and challenging place to work at.
From my personal experience the following mindset forms the basis of such a team.
We truly care about things
Caring means acting
Caring means pushing things forward
Caring means questioning ideas, concepts and decisions
Caring means listening to customer feedback
Caring means answering questions and providing feedback in time
Caring means continually monitoring project progress
We are pragmatic while caring about things
Failures happen, but we are able to quickly analyze, find and fix them
Logging helps us in analyzing and finding bugs quickly (without long-lasting debugging sessions)
Simple and elegant design help us in fixing problems instantly as well as in maintaining and refactoring our code base without fear
Tooling is very important to achieve fast bug fixing turnaround times
We communicate openly
Open communication means keeping others informed
Open communication works like a push system, not like a pull system
Open communication must no result in overstimulation by steady interruptions
To understand is to invent
We keep asking why and question until we understand all the stuff
Understanding all the code and technologies is a prerequisite to quality
Best Practices
Strive for simplicity
Keep an eye out for beauty and aesthetics in your code base no matter if it is about architecture, naming or something else
Reduce risk by integrating early and often
Read code, review code! By reading code one learns so much, both from the good and the bad parts of the code base
Societies have operating systems: the laws, social customs and economic arrangements sit atop a layer of instructions, protocols and suppositions about how the world works.
A big part of our societal operating system consists of a set of assumptions about human behavior.
Societal OS v1.0 code name "Try to survive" was the operating system in place at the beginning of human mankind
Societal OS v2.0 code name "Humans are more than the sum of their biological urges" is the operating system that currently has the biggest installed base
Supports more complex societies
Cooperation
Rewards and punishments to build and scale complex economies
Profit maximization
Enabler for the industrial revolution
Algorithmic, rule-based work
Societal OS v3.0 code name "Intrinsic motivation" currently has a small but growing installed base out there
Purpose maximization
Social benefit principle
Supports really complex societies
Powerful, new business models: Open-source
Humans have a drive to learn, to create and to make to world a better place
Effectiveness
Heuristic tasks
Intrinsic motivation
Intrinsic motivation depends on autonomy, mastery and purpose.
To develop intrinsic motivation an undertaking itself must provide freedom, challenge and purpose to the people.
Self-Determination Theory
The self-determination theory describes three innate human needs: competence, autonomy and relatedness.
Satisfying these needs results in motivation, productivity and happiness.
The Open-Source Movement
Enjoyment-based intrinsic motivation is the strongest and most pervasive driver
The fun of mastering a given software problem and the desire to give a gift to the community
Social benefit principle replaces maximum profit principle
Open-source people are mostly intrinsically motivated purpose maximizers
Open-source people love creativity, interest and self-direction
Flow Flow in positive psychology is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. People can frequently reach "flow" in case of optimal challenges.
Flow, the deep sense of engagement, is the oxygen of the soul we need to survive
People are much more likely to reach a flow state at work than in leisure
Why at work? Maybe due to clear goals, immediate feedback, challenges matching to our abilities
This way, organizations can enrich people's lives
Autonomy and Self-Direction
Autonomy over 4 aspects of work: what people do, when they do it, how they do it and whom they do it with
People should focus on the undertaking itself rather than on the time to do it
People should contribute rather than just show up and grind out the day
The opposite of autonomy is control. Control leads to compliance, autonomy leads to engagement
The billable hour is a relic of societal OS 2.0
Mastery
Mastery is the desire to get better and better at something that matters
Only engagement produces mastery
The modern workplace's most notable feature may be its lack of engagement and its disregard for mastery
Flow is essential to mastery
Grit may be as essential as talent to high accomplishment
Mastery is an asymptote. You can approach it without ever reaching it
Mastery can be an ethic for living
Mastery is a mindset! -> Intelligence is something you can develop
Mastery is a pain! -> Mastery requires effort over a long time
Does your company or team have and share a mastery mindset?
Carol Dweck: What people believe shapes what people achieve.
Our believes about ourselves and the nature of our abilities (our self-fears) determine how we interpret our experiences and can set the boundaries on what we accomplish
Effort is one of the things that gives meaning to life. Effort means you care about something, that something is important to you and you are willing to work for it
It would be an impoverished existence if you were not willing to value things and commit yourself to working toward them
Purpose
It is in our nature to seek purpose
The secret to high performance isn't our biological drive or our reward and punishment drive but our third drive: our deep-seated desire to direct our own lives, to extend and expand our abilities, and to live a life of purpose
Societal OS 3.0 is built for purpose maximization
Purpose maximization is about seeking the right goals
A healthy society or healthy organization needs sustainable purpose
"They" and "we" companies are very different places
What is your company's purpose?
What gets you up at morning? What keeps you up at night?
Extrinsic motivation
Good for algorithmic, rule-based tasks
If-then rewards require people to forfeit some of their autonomy and therefore undermining the intrinsic motivation toward the activity
Try to offer now-that rewards instead of if-then rewards by praising and providing positive feedback with useful information
Rewards narrow people's focus
Goals may narrow people's focus, decrease cooperation and decrease intrinsic motivation
"The greatest achievement of our technology may well be the creation of tools that allow us to go beyond engineering - that allow us to create more than we can understand."
