Monday, June 5, 2017

Frederick Brooks on Software Design

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.

Monday, April 17, 2017

Alan Kay on Computer Science

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.

See also: Alan Kay on Object-Oriented Programming

Normal Considered Harmful

  • 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.
  • 14:33 WYSIATI: What you see is all there is.
  • 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)

Sunday, April 16, 2017

Operating System 101

From Andrew S. Tanenbaum's "Tanenbaum-Torvalds Debate - Part II".
No flame wars, just operating system and distributed system architecture.

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.

See also: Microkernels are slow and Elvis didn’t do no drugs

Friday, April 7, 2017

On Building Reliable Automotive Software Systems

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.java targets the Java platform
  • 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.

See also:

Saturday, March 11, 2017

Characteristics of an efficient engineering team

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
  • Fail fast, but don't give up too easily

Friday, February 24, 2017

Psychology and Behavioral Science (not just) for Computer Scientists

This post contains some few excerpts from the book Drive: The Surprising Truth About What Motivates Us from Daniel H. Pink.
The field of psychology and behavioral science currently preoccupies me a lot mostly due to personal struggles in seeking purpose.

Societal Operating Systems

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

See also: