MASTER PEACE
Lateral thinking is a term coined by Edward de Bono in his book New Think: The Use of Lateral Thinking in 1967; it refers to solving problems through an indirect and creative approach. Lateral thinking is about reasoning that is not immediately obvious and about ideas that may not be obtainable by using only traditional step-by-step logic.

Lateral thinking and problem solving

Problem Solving: When something creates a problem, the performance or the status quo of the situation drops. Problem solving deals with finding out what caused the problem and then figuring out ways to fix the problem. The objective is to get the situation to where it should be.
For example, a production line has an established run rate of 1000 items per hour. Suddenly, the run rate drops to 800 items per hour. Ideas as to why this happened and solutions to repair the production line must be thought of.


Creative Problem Solving: Using creativity, one must solve a problem in an indirect and unconventional manner.
For example, if a production line produced 1000 books per hour, creative problem solving could find ways to produce more books per hour, use the production line, or reduce the cost to run the production line.

Creative Problem Identification: Many of the greatest non-technological innovations are identified while realizing an improved process or design in everyday objects and tasks either by accidental chance or by studying and documenting real world experience.

THE SOFTWARE MASTER-PEACE
> It lets you design software on as many levels of abstraction as you like.
> It lets you zoom in/out of a design like Google maps.
> It lets you watch the execution in slow-motion.
> It lets you switch on/off tracing at runtime.
> It lets you focus your actual code slinging at small functional units
> so the source code stays easy to read.
> It lets you distribute the functional units to code among the team for high speed parallel work on them.
>
> And so I very firmly believe: Source code is not the end, but just a beginning.

If software development is a team effort, how then is the design of a software most efficiently and effectively communicated:
a. among team members, if one part of the team changed it and another part needs to work on the changed parts?
b. to new team members who have no/little knowledge of the overall software system?
By "efficient" I mean quickly. How long does it take to inform
somebody about a design?
By "effectively" I mean, the person getting informed about the design
should finally have the same mental model of the design as the others,
and this mental model should mostly closely match the de facto design.
By "design" I mean overall system structure: which functional units
are there, what´s their purpose, how do they interact to realize some
user value (fulfil certain requirements, e.g. implement a feature).