The Mythical man-month - Frederick P. Brooks jr.

• Efforts
• standalone program *3 to develop program that works on any system
• standalone program *3 to develop program to programming product which works with other programs
• standalone program *9 to develop program that works on all systems together with other programs
• Only this is a truly useful project
• Why is programming fun?
• Sheer joy of making things
• useful to other people
• we want others to use our work and find it helpful
• fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work
• Joy of always learning
• The programmer, like the poet, works only slightly removed from pure thought-stuff by exertion of the imagination
• Woes of programming
• One must perform perfectly
• other people set one's objective
• One rarely controls the circumstances of his work or even its goal.
• One's authority is not sufficient for his reponsibility
• (Here agile tries to bring responsibility and authority together)
• Designing grand concepts is fun; finding nitty little bugs is just work
• debugging has a linear convergence, the last difficult bugs taking more time to find than the first
• the technological base on which one builds is always advancing
• as soon as one freezes a design, it becomes obsolete
• implementation of real products demands phasing and quantizing. The obsolescene of an implementatino must be measured against other existing implementations, NOT against unrealized concepts
• (excecution is what counts)
• (better done than perfect)
• Good cooking takes time. If you are made to wait, it is to serve you better, and to please you
• More software projects have gone awry for lack of calendar time than for all other causes combined
• All programmers are optimists
• Perhapts the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal.
• So the first false assumption that underlies the scheduling of systems programming is that ALL WILL GO WELL, i.e. that EACH TASK WILL ONLY TAKE AS LONG AS IT "OUGHT" TO TAKE
• A large programming effort, however, consists of many tasks, some chained end-to-end. The probability that each will go well becomes vanishingly small
• Men and months are interchangeable commodities only when a task can be partitioned among many workers with NO communication among them
• The bearing of a child takes nine months, no matter how many women are assigned
• Many software tasks have this characteristic because of the sequential nature of debugging
• the effort of communication must be added to the amount of work to be done.
• The added burdon of communication is made up of two parts: training and intercommunication
• Each worker must be trained
• Intercommunicatino is worse - efforts increases as n(n-1)/2
• It quickly dominates the decrease in individual task time.
• Adding more people then lengthens, not shortens, the schedule.
• Therefore, testing is usually the most mis-scheduled part of programming
• 1/3 planning + 1/6 coding + 1/4 component test and early system test + 1/4 system test, all components at hand 
• 33% plan, 17% build, 50% test
• no one is aware of schedule trouble until almost the delivery date.
• delay at this point has unusually severy financial, as well as psychological, repercussions
• An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices . wait or eat it raw. Software customers have the same choices.
• What does one do when an essential software project is behind schedule? Add manpower naturally
• Or trim the task
• BROOKS LAW: "Adding manpower to a late software project makes it later."
• (therefore decompose tasks, small scopes - agile delivery = usable increments)
• Wide productivity variations between good programmers and poor ones
• 10:1
• The data showed no correlation whatsoever between experience and performance
• small, sharp teams max 10 people (this is exactly scrum team size)
• Most European cathedrals show differences in plan or architectural style between parts build in different generations by different builders. The later builders were tempted to "improve" upon the designs of the earlier ones, to reflect both changes in fashion and differences in individual taste. 
• Against these, the architectural unity of Reims stands in glorious contract. This integrity was achieved by the self-abnegation of eight generations of builders, each of whom sacrificed some of his ideas so that the whole might be of pure 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.
• (Airport Berlin desaster with steadily changing scope)
• Similarly, I observe that the external provision of an architecture enhances, not cramps, the creative style of an implementing group. They focus at once on the part of the problem no one has addressed, and inventions begin to flow. In an unconstrained implementing group, most thought and debate goes into architectural decisions, and implementation proper gets short shrift.
• "We finally decided to implement the language unchanged and unimproved, for the debates about language would have taken all the effort."
• The fundamental answer is thoroughgoing, careful, and sympathetic communication between architect and builder..
• An architect's first work is apt to be spare and clean. He knows he doesn't know what he's doing.
• An ancient adage warns, "Never go to sea with two chronometers, take one or three."
• He found his programming teams missing schedules by about one-half
• showed that the estimating error could be entirely accounted for by the fact that his teams were only realizing 50 percent of the working week as actual programming and debugging time. Machine downtime, higher-priority unrelated jobs, meetings, paperwork, company business, sickness, personal time etc accounted for the rest 
• In short, the estimates made an unrealistic assumption about the number of technical work hours per man-year.
• "It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something." - Franklin D. Roosevelt
• In most projects, the first system build is barely usable. It may be too slow, too big, awkward to use, or all three.
• The management question, therefore, is not WHETHER to build a pilot system and throw it away. You WILL do that. The only question is wether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.
• Hence, plan to throw one away; you will, anyhow
• Managers themselves often think of senior people as "too valuable" to use for actual programming. Next, management jobs carry higher prestige. To overcome this problem some laboratories, such as Bell Labs, abolish all job titles. Each professional employee is a "member of the technical staff"
• Managers need to be sent to technical refresher courses, senior technical people to management training. Project objectives, progress, and management problems must be shared with the whole body of senior people
• Whenever talents permit, senior peope must be kept technically and emotionally ready to manage groups or to delight in building programs with their own hands. 
• It has the effect of making a senior man feel that he does not demean himself when he builds programs, and it attempts to remove the social obstacles that deprive him of that creative joy.
• We rebuild the developing system every night [and run test cases]. The build cycle becomes the heartbeat of the project. Every day one or more of the programmer-tester teams check in modules with new functions. After every build, we have a running system.
• In particular, adding extra manpower early in the schedule is a much safer maneuver than adding it later, since the new people always have an immediate negative effect.
  

Tatort Kanban

• Stop starting, start finishing
• Fokus auf das Beenden von Aufgaben
• Wert für den Kunden im Zentrum
• Manage work, not people
• parallele Tätigkeiten limitieren
• Abhängigkeiten reduzieren
• Kanban kommt aus dem japanischen und heißt so was wie Signalkarte
• Agilität: Schnelligkeit, Anpassung, Dynamik, Selbstorganisation
• Kybernetik: Selbstorganisation ist der normale Weg. Deswegen muss Selbstorganisation als die Regel und nicht die Ausnahme systemischen Verhaltens betrachtet werden.
• work in progress limit in kanban
• In diesem Arbeitsschritt wird an maximal zehn Dingen parallel gearbeitet
• Dadurch, dass ab der Spalte Next jede Aktivitätenspalte limitiert ist, verhindern wir, dass wir mit Arbeit überschwemmt werden - was bekanntilch nicht Fluss, sondern Stau fördert.
• dass wir damit die an uns gestellten Anforderungen und unser aktuelles Leistungsvermögen möglichst gut im Gleichgewicht halten.
• Was passiert auf einer Autobahn, wenn dort zu viele Autos fahren.
• langsamer
• Genau, der Verkehrsfluss hat ein natürliches Limit.
• Es wir immer zähflüssiger, wenn noch mehr Autos auf die Autobahn strömen.
• Es geht immer langsamer bis alles steht
• Dann kommt die Polizei und löst es:
• Der Zufluss wird so geregelt wie es die Ampeln an den Auffahrten zur Autobahn tun. Gleichzeitig wir die Durchschntissgeschwindigkeit gesenkt (dynamische Anzeigen auf der Autobahn die bei starkem Verkehr auf 120/100/80 runterregeln), damit der Verkehr nicht zum Erliegen kommt
• Auch in der Produktion wird seit vielen Jahren auf bewusste Limitierung gesetzt. Nur in der Wissensarbeit werden diese einfachen Flussprinzipien immer noch weitgehend ignoriert.
• Kassasturz
• gemeinsam innezuhalten und nicht einfach so weiterzumachen, bis man nur noch kopflos agierte. 
• Zeit und Raum, um ihre Erfahrungen zu sortieren.
• erst einmal nachzudenken und Einsichten zu gewinnen
• Welchen Sinn hatte es, immer mehr Informationen zu sammeln, wenn einem der Überblick fehlte
• 
   

Rich dad, poor dad - Robert Kiyosaki

• If you learn lifes lessons, you will do well. If not, life will jsut continue to push you around.
• Life pushes all of us around. Some people give up and other fight. A few learn the lesson and move on. They welcome life pushing them around. To these few people, it meand they need an want to learn something. They learn and move on. Most quit, and a few fight.
• If you learn this lesson, you will grow in to a wise, wealthy, and happy young man. If you dont, you will spend your life blaming.
• If you think I am the problem, then you have to change me. If you realize that youre the problem, then you can change yourself, learn something, and grow wiser. Most people want everyone else in the world to change but themselves. Let me tell you, it's easier to change yourself than everyone else.
• The pattern of get up, go to work, pay bills; get up, go to work, pay bills. Peoples lives are forever controlles by two emotions: fear and greed: Offer them more mone and they continue the cycle by increasing their spending. This is what I call the Rat Race.
• A job is really a short-term solution to a long-term problem (having to pay expenses)
• Its not how much money you make. Its how much money you keep.
• The rich focus on their asset columns while everyone else focuses on their income statements.
• There is a big difference between your profession and your business. I often ask people, "What is your business?" and they will say "Oh, I am a banker." Then I ask them if they own the bank. "No, I work there.". In that instance, they have confused their profession with their business. Their profession may be a banker, but they still need their own business
• Their business is selling their labour to the bank. It doesnt scale. There is only so much time you have. Time for income, not for assets
  
•  Too many people forget to mind their own business. They spend their lives minding someones elses business and making that person rich
• Start minding your own business. Keep your daytime job, but start buying real assets, not liabilities or personal effects that have no real value once you get them home. A
• Keep expenses low, reduce liabilitites, and diligently build a base of solid assets.
• The economy was terrible at that time. For investors, this is the perfect market condition.... Because people were giving properties away I was buying.I was not saving money. I was investing.
• It says best-selling author, not best-writing.
• But a savvy investor knows that the seemingly worst of times is actually the best of times to make money. When everyone else is too afraid to act, they pull the trigger and are rewarded.
• A friend of mine recently had her apartment burglarized. The thieves took her leectronics and left all the books. And we all have that same choice. 90% of the population buys TV sets, and only about 10% buy business books.
• This is because, in the market, it is usually the crowd that shows up late that is slaughtered. If a great deal is on the frnot page, its too late in most instances. Look for a new deal.
• This is hard for most investors because buying what is not popular is frightening.
• Money is only an idea. If you want more money, simply change your thinking.
  

"Do cats eat bats?" and sometimes "Do bats eat cats?" for, you see, as she couldn't answer either question, it didn't much matter which way she put it.

 

"Zeit hat man nicht, Zeit nimmt man sich."

 

Your mind is good in having ideas, not in holding them. - David Allen

 

There is no elevator to success, you have to take the stairs.