vault backup: 2025-02-05 14:38:06
This commit is contained in:
@@ -0,0 +1,91 @@
|
||||
---
|
||||
title: Atomic Habits by James Clear
|
||||
created_date: 2024-10-23
|
||||
updated_date: 2024-10-23
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
type: book
|
||||
book_name: Atomic Habits
|
||||
author: James Clear
|
||||
status: not_started
|
||||
---
|
||||
# Atomic Habits by James Clear
|
||||
- **🏷️Tags** : #10-2024 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> **Atomic Habits by James Clear** is about using the power of habits as a system to incrementally become the person you want to be by leveraging the compounding nature of habits. The core idea is to find good habits and make them *obvious, attractive, easy and satisfying*, as well as identifying your bad habits and making them *invisible, unattractive, hard and unsatisfying*. Personally, a key takeaway is to get started doing a habit as soon as possible, by starting smaller than what your end goal is (read 1 page instae, without trying to optimise everything beforehand.
|
||||
|
||||
Missing: Identity, Environment, ...
|
||||
## Cheatsheet
|
||||
### How to create a good habit
|
||||
|
||||
| **The 1st Law** | **Make It Obvious** |
|
||||
| --------------- | -------------------------------------------------------------------------------------- |
|
||||
| 1.1 | Fill out the Habits Scorecard. Write down your current habits to become aware of them. |
|
||||
| 1.2 | Use implementation intentions: "I will [BEHAVIOR] at [TIME] in [LOCATION]." |
|
||||
| 1.3 | Use habit stacking: "After [CURRENT HABIT], I will [NEW HABIT]." |
|
||||
| 1.4 | Design your environment. Make the cues of good habits obvious and visible. |
|
||||
|
||||
|**The 2nd Law**|**Make It Attractive**|
|
||||
|---|---|
|
||||
|2.1|Use temptation bundling. Pair an action you want to do with an action you need to do.|
|
||||
|2.2|Join a culture where your desired behavior is the normal behavior.|
|
||||
|2.3|Create a motivation ritual. Do something you enjoy immediately before a difficult habit.|
|
||||
|
||||
|**The 3rd Law**|**Make It Easy**|
|
||||
|---|---|
|
||||
|3.1|Reduce friction. Decrease the number of steps between you and your good habits.|
|
||||
|3.2|Prime the environment. Prepare your environment to make future actions easier.|
|
||||
|3.3|Master the decisive moment. Optimize the small choices that deliver outsized impact.|
|
||||
|3.4|Use the Two-Minute Rule. Downscale your habits until they can be done in two minutes or less.|
|
||||
|3.5|Automate your habits. Invest in technology and one-time purchases that lock in future behavior.|
|
||||
|
||||
| **The 4th Law** | **Make It Satisfying** |
|
||||
| --------------- | --------------------------------------------------------------------------------------------- |
|
||||
| 4.1 | Use reinforcement. Give yourself an immediate reward when you complete your habit. |
|
||||
| 4.2 | Make "doing nothing" enjoyable. When avoiding a bad habit, design a way to see the benefits. |
|
||||
| 4.3 | Use a habit tracker. Keep track of your habit streak and "don't break the chain." |
|
||||
| 4.4 | Never miss twice. When you forget to do a habit, make sure you get back on track immediately. |
|
||||
|
||||
### How to Break a Bad Habit
|
||||
|
||||
| **Inversion of the 1st Law** | **Make It Invisible** |
|
||||
| ------------------------ | -------------------------------------------------------------------------- |
|
||||
| 1.5 | Reduce exposure. Remove the cues of your bad habits from your environment. |
|
||||
|
||||
| **Inversion of the 2nd Law** | **Make It Unattractive** |
|
||||
| ------------------------ | ------------------------------------------------------------------------- |
|
||||
| 2.4 | Reframe your mindset. Highlight the benefits of avoiding your bad habits. |
|
||||
|
||||
| **Inversion of the 3rd Law** | **Make It Difficult** |
|
||||
| ------------------------ | ----------------------------------------------------------------------------------- |
|
||||
| 3.6 | Increase friction. Increase the number of steps between you and your bad habits. |
|
||||
| 3.7 | Use a commitment device. Restrict your future choices to the ones that benefit you. |
|
||||
|
||||
| **Inversion of the 4th Law** | **Make It Unsatisfying** |
|
||||
| ---------------------------- | ------------------------------------------------------------------------------ |
|
||||
| 4.5 | Get an accountability partner. Ask someone to watch your behavior. |
|
||||
| 4.6 | Create a habit contract. Make the costs of your bad habits public and painful. |
|
||||
|
||||
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
Personally, a key takeaway is to get started doing a habit as soon as possible by starting smaller than what your end goal is (read 1 page, instead of 1 hour). All this without trying to optimise everything beforehand ([[analysis paralysis]]).
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
|
||||
---
|
||||
```query
|
||||
Atomic Habits James Clear
|
||||
-file: "Atomic Habits by James Clear.md"
|
||||
```
|
||||
@@ -0,0 +1,44 @@
|
||||
- Man muss Geld ausgeben um Geld zu verdienen
|
||||
- Kapitalismus ist eng verknüpft mit Spezialisierung, da dadurch mehr produziert werden kann, günstiger angeboten werden kann und somit mehr Geld verdient werden kann. ![[image 14.jpg]]
|
||||
- Die unsichtbare Hand beschreibt den Wettbewerb, den die Unternehmer dazu bringt faire Preise anzubieten, auch wenn sie die Kunden ausnehmen möchten. Sonst laufen die Kunden zu der Konkurrenz.
|
||||
- Die Grenzen des Marktes gemäss [[Adam Smith]], heisst Aufgaben des Staates:
|
||||
- Zinssatz deckeln: sonst gamblen die Leute auf hohe Profite
|
||||
- Kriegsnahe Industrien fördern, um bereit zu sein
|
||||
- Lohnarbeiter schützen, weil sie eine schlechtere Verhandlungsposition haben
|
||||
- Ehrlichkeit der Banken garantieren
|
||||
- Patente garantieren
|
||||
- Neue Industrien schützen
|
||||
- Krankheiten bekämpfen
|
||||
- Volksbildung garantieren und Massstäbe setzen
|
||||
- Für öffentliches Vergnügen sorgen
|
||||
- Hohe Preise (Inflation) und niedrige Löhne sind daselbe —> *Reallohn*
|
||||
- Der Gesellschaft geht es besser wenn die Mehrheit (Arbeitsnehmer) gute Löhne haben
|
||||
- Vorschläge für Gesetzesänderungen immer mit Misstrauen betrachten, da sie oft von Kapitalisten kommen, die durchs Eigeninteresse mehr Profit wollen und die Gesellschaft unterdrücken wollen
|
||||
- Die freie Wirtschaft für Smith war die Wirtschaft in der staatliche Gesetze nicht den Kapitalisten einen Vorteil verschafften —> er wollte die Gesetze entfernen um eine faire freie Wirtschaft aufzubauen. (Also keine staatlich geförderte Monopole, keine Regulierungen, Subventionen, etc die einzelne Profiteure hatte)
|
||||
- Komparativer Kostenvorteil von [[David Ricardo]]:
|
||||
- Internationaler Handel: Fokus auf effiziente Güter: auch wenn ich da ein Produktivitäts Nachteil habe ist dieser geringer und somit profitiere ich
|
||||
- [[Klassische Politische Ökonomie]]
|
||||
|
||||
---
|
||||
Der erste Börsencrash/Flaute war weil die Leute kein Geld hatten um Waren zu kaufen, und somit wurde weniger produziert und weniger Leute angestellt —> ein Teufelskreis
|
||||
|
||||
Man konnte nicht einfach mehr Geld drucken wegen den Goldstandard: das Papiergeld ist an die Menge Gold gekoppelt.
|
||||
|
||||
Geld ist nur dann etwas wert, wenn man vertraut damit etwas anderes kaufen zu können, weil andere Leute auch vertrauen, dass es funktioniert.
|
||||
|
||||
Durch die Mindestreserven (sagen wir mal 20%) bei einer Bank kann Geld mittels Schuldscheinen generiert werden. $1000 in cash wird dann zu $5000 fiktivem Geld, welches im Umlauf ist. Solche Kredite kurbeln die Wirtschaft an.
|
||||
|
||||
Bourgoisie: die Kapitalisten
|
||||
Proletariat: die Arbeiter, die verarmte Masse
|
||||
|
||||
1848 gab es viele Revolutionen, die Idee war, dass das Proletariat stärker wurde und die Kapitalisten ersetzen würde, also das schlussendlich in der Fabrik alle für alle arbeiten würden.
|
||||
|
||||
---
|
||||
Amerika
|
||||
Gutbezahlte Arbeiter, arbeiten besser als schlecht bezahlte, weil sie eine Zukunft sehen, eine Motivation sehen die höher ist als das blosse Existenzminimum.
|
||||
|
||||
Neoklassische Ökonomie: Angebot und Nachfrage
|
||||
|
||||
---
|
||||
**Blase oder Bubble**: Leute kaufen etwas *weil* der Preis steigt. Ihre Käufe treiben den Preis weiter in die Höhe.
|
||||
|
||||
@@ -0,0 +1,279 @@
|
||||
---
|
||||
title: More Effective Agile by Steve McConnell
|
||||
created_date: 2025-01-13
|
||||
updated_date: 2025-01-13
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
type: book
|
||||
book_name: More Effective Agile
|
||||
author: Steve McConnell
|
||||
status: not_started
|
||||
---
|
||||
# More Effective Agile by Steve McConnell
|
||||
- **🏷️Tags** : #01-2025 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
|
||||
|
||||
> [!Quote] Inspect, Adapt & Grow
|
||||
> Contents
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
> [!info] Import Clippings from Kindle
|
||||
> Annotate Clippings with thoughts and cross references
|
||||
|
||||
### Thoughts and Ideas
|
||||
- Assign Scrum Master Role to some team member
|
||||
- Team setup: does scrum work with hardware and mixed teams?
|
||||
- Who is product owner?
|
||||
- What roles do we want?
|
||||
|
||||
|
||||
---
|
||||
### What's Really Different About Agile?
|
||||
Main Benefits of Agile vs Sequential:
|
||||
- Short release cycles allow for more timely and less expensive correction of defects and faster feedback loops, meaning you can learn and adapt faster.
|
||||
- End-to-End development in small batches allows for testing and faster feedback loops
|
||||
- Just-in-time planning doesn't waste time creating plans that are then thrown away.
|
||||
- Just-in-time requirements results in less time invested upfront for requirements that might eventually be discarded
|
||||
- Continuous automated testing is very powerful
|
||||
- Frequent, structured collaboration: daily scrum, sprint planning, sprint retrospective
|
||||
- focus on empirical, responsive improvement model allows the team to learn and grow fast.
|
||||
|
||||
### Responding to the Challenges of Complexity and Uncertainty
|
||||
|
||||
#### Cynefin
|
||||
Cynefin means *habitat* or *neighbourhood* in Welsh and they are considered to be clusters of meaning.
|
||||
5 Domains: Complex, Complicated, Chaotic, Obvious, Disorder
|
||||
|
||||
![[Pasted image 20250115111654.png]]
|
||||
|
||||
In the **Obvious domain**, problems are well understood and clear. Example problems are taking an order at a restaurant, filling a car with gasoline, etc. The approach to solving them is *sense, categorize, respond*. There are only miniature problems like detailed if statements with live within this domain in software development, all other problems are not in this domain, which is why we can safely ignore it.
|
||||
|
||||
In the **Complicated Domain** you know the general shape of the problem, what question to ask and how to obtain answers. Multiple correct answers exist and you need to find the relationship between cause and effect. This is often hard, which makes this domain the domain of experts. The approach to solving problems is *sense, analyze, respond*, note the analysis instead of categorizing in the second step. Example problems: prepare a gourmet meal, database query for certain results, prioritize user requirements for version 4.1 of a mature system, etc. A lot of software development falls within this domain, and a sequential linear approach can work.
|
||||
|
||||
In the **Complex Domain** the relationship between cause and effect is not immediately clear, even to experts. You don't know all the questions to ask - finding the right questions is part of the challenge. Experimentation is needed to progress, some amount of failure is part of the process and decisions are often made on the basis of incomplete data. The approach to those problems is *probe, sense, respond*, meaning you can't analyze your way out of problems, but you need to probe and experiment with different solutions to start. Examples are buying a gift for someone who is difficult to shop for, meaning you know you most likely will need to exchange it later; Fixing a bug, which is not found during debugging, but only in production systems; creating software for changing hardware that is evolving. Many software development problems fall into this domain and this is where agile excells.
|
||||
|
||||
In the **Chaotic Domain** there is no discoverable relationship between cause and effect even with extended probing, because it is in constant turbulence. This domain also includes a time pressure element, which other domains lack. The approach to problems in this domain are decisive, action-oriented in order to impose order onto the chaos: *act, sense, respond*. Examples of such problems are: provide natural disaster help, while it is still happening; stopping a food fight in a highschool cafeteria; defining a feature set in a highly political environment with powerful stakeholders; fixing a bug in production by reversing the version, because no probing nor analysis has found the bug. The sizes of the problems are mostly smaller than project size for typical software projects.
|
||||
|
||||
In the **Disorder Domain** you lack clarity which domain applies to your problem. The approach here is to decompose the problem into subelements and assess the domains of each subelement. Remember that each project might have problems in various domains.
|
||||
|
||||
![[Pasted image 20250115111900.png]]
|
||||
As shown in the graph above, it is always better to use an agile approach and maybe sacrifice some efficiency if your problem was only complicated. The other way round could be disastrous and lead to the cancellation of the project.
|
||||
|
||||
#### Succeeding on Complex Projects: OODA
|
||||
![[Pasted image 20250115113740.png]]
|
||||
The origin of OODA was the US military in order to accelerate decision making. It is a method to establish context, formulating a plan, performing work observing results and incorporating learnings into the next cycle.
|
||||
|
||||
**Observe** the current situation, outside information that is relevant and any aspects of the situation that are unfolding (emergent). OODA places a strong emphasis on observation, experience and learning and thus is very empirical.
|
||||
|
||||
**Orient** is where you relate the observations to your situation, meaning you decide how the observations are relevant to you and your current situation and how possible responses look like. This is an opportunity to challenge your assumptions, adjust for cultural and company cultural blind spots, de-biasing data and information. A classical example is the first iPhone, which was technically inferior to many other phones, but solved the user experience problem instead, which turned out to be more important.
|
||||
|
||||
**Decide** is where you make a decision based the observations and the orientation in the previous two steps. The goal is to disrupt the opponents OODA-loop by forcing them to play your game instead of you playing their game.
|
||||
|
||||
**Act** is finally where you implement the decision, after which you start over in the cycle by observing the impact of your actions and learning from them.
|
||||
|
||||
In contrary to sequential development practices, OODA considers uncertainty as opportunity to act and create something new, something you can exploit to gain an advantage over your opponent.
|
||||
|
||||
|
||||
> [!important] Inspect and Adapt
|
||||
> Inspect and Adapt is a useful shorthand for OODA. Agile teams should avoid being idealistic about their practices and instead adjust their practices based on empirical observations about what has been proved to work. Apply Inspect and Adapt to *everything* (plans, designs, code quality, tests, processes, team interactions, organizational interactions, etc), meaning every factor that can make a difference to a team's effectiveness.
|
||||
|
||||
### More effective Agile beginnings: Scrum
|
||||
|
||||
- [ ] Summarize everything until failure mode #todo/b
|
||||
|
||||
The main common failure is not to use SCRUM in its entirety, but only implement certain parts. Scrum is already broken down to the minimum processes, everything you take away in addition will break the system (might not apply to power scrum users, but certainly to beginners).
|
||||
#### Most common Challenges
|
||||
- **Ineffective Product Owner**: Before agile the most common source of failure was poor definition of requirements. Since the product owner is responsible for requirements it comes at no surprise that this is a common challenge. Businesses should treat this role as the highest leverage role for the scrum team and fill it accordingly. With former training business analysts, customer support staff and testers can make excellent POs.
|
||||
- No Product Owner
|
||||
- Only 1-2 teams per product owner
|
||||
- PO doesn't understand the business
|
||||
- PO doesn't understand how to specify software requirements
|
||||
- PO doesn't understand the Development team's technical challenges, thus does not effectively prioritize --> accumulation of technical debt
|
||||
- PO is not co-located with the rest of the Scrum team --> no timely answers to requirement questions
|
||||
- PO is not empowered to make product decisions
|
||||
- PO's agenda differs from the business's: team works towards a different goal than the business
|
||||
- PO does not represent typical users --> for example: PO is a power user of the software
|
||||
- PO refuses to abide by scrum rules --> change requirements mid sprint, or other disruptions
|
||||
- **Insufficient Product Backlog refinement**: the backlog is the developer's food and you never want to starve your development team. The PO's job is to update the backlog continuously and keep it high quality. Split too long stories into 2, write down details of other stories to create nice work packages for the developers,
|
||||
- **Stories Too large**: should be completable within a single sprint. For a team of recommended size (3-9) aim for 6-12 stories per sprint. The maximum story size should consume max half the team for max half the sprint, most stories should be smaller
|
||||
- **Daily Standup not held daily**: Stick to it, no matter what. Focus on the 3 questions: what did you do yesterday, what do you do today, what is blocking progress? Keep it time boxed to 15 minutes --> max 2 minutes or so per person.
|
||||
- **Overly long sprints**: Most sprints are 2 weeks. 3 weeks or longer is too risky because of: planning mistakes, too optimistic commitments, procrastination and so on.
|
||||
- **Emphasis on Horizontal Slices Rather than Vertical Slices**: Vertical slices refer to end-to-end functionality across the technology stack. horizontal slices on the other hand do not produce any demonstrable business-level functionality. Focusing on vertical slices supports better feedback loops and earlier delivery of business value.
|
||||
- **Separate Development Teams and Test Teams**: A common holdover from sequential development. Scrum team needs cross-functional expertise to operate effectively.
|
||||
- **Unclear Definition of Done (DoD)**: When something is marked as done, the team should have confidence that it is actually done, meaning no more work remains for that item in order to add it to the production release.
|
||||
- **Not Driving to a Releasable Level of Quality Each Sprint**: Excessive schedule pressure is that team puts focus on appearance of progress above actual progress. Another example is skipping the testing, in order to get more actual code done (also related to DoD). Successful agile teams drive each story to production level before tackling the next one.
|
||||
- **Retrospectives not held**: when feeling overwhelmed by the amount of work, teams often skip retrospectives. This is a huge mistake! Without it you don't learn from planning and commitment mistakes leading to the same problem over and over again.
|
||||
- **Retrospectives not Implemented in the next sprint**: doing the retrospectives, but not applying the learnings. This means you cannot progress.
|
||||
- **Scrum And**: You don't need more than scrum to start.
|
||||
- **Ineffective Scrum Master**: Scrum master is responsible for avoiding these failure modes.
|
||||
- No scrum master
|
||||
- Scrum Master is supporting too many teams
|
||||
- Dual Scrum Master prioritizes development work over Scrum work
|
||||
- Scrum Master does not understand Scrum well enough to coach the team and project stakeholders
|
||||
|
||||
All points above share that they usually diverge from pure Scrum, meaning they implement "Scrum, but...". Further all attributes demand high discipline practices, meaning if the system is not properly set-up the people tend to drift away from it. The scrum master is responsible for ensuring those practices and the meetings (sprint planning, daily scrum, sprint review and sprint retrospective) provide structural support as well as social support to stick to the scrum.
|
||||
|
||||
|
||||
> [!Tip] Success Factors in Scrum
|
||||
> Each of the failure modes above can be converted into a success factor.
|
||||
|
||||
#### A Successful Sprint
|
||||
A successful sprint will support the main goal of Scum which is maximizing the value of the product:
|
||||
- deliver usable, valuable increment (aggregate functionality) fulfilling DoD.
|
||||
- the sprint's increment increases in value compared to the previous sprint
|
||||
- the Scrum process is improved compared to the previous sprint
|
||||
- Scrum team learns something about itself, its business, its product or its customers
|
||||
- Motivation remains the same or increases with each sprint
|
||||
|
||||
The time allocation per developer should be something like the following (out of 60 hours: 6h project focus for 10 business days. Startups have less overhead and thus more likely 7-8h of project work per day):
|
||||
- *48h* development work, including testing
|
||||
- *2h* daily standups
|
||||
- *3h* product backlog refinement (5%)
|
||||
- *4h* sprint planning
|
||||
- *2h* sprint review
|
||||
- *1h* sprint retrospective
|
||||
|
||||
Summarizing: 80% of the work should go into development and 20% into planning and process improvement.
|
||||
|
||||
#### A Scrum Scorecard
|
||||
![[Pasted image 20250115121640.png]]
|
||||
|
||||
|
||||
| Score | Description |
|
||||
| ----- | ------------------------------------------ |
|
||||
| 0 | Not used |
|
||||
| 2 | used infrequently and ineffectively |
|
||||
| 4 | Used occasionally with mixed effectiveness |
|
||||
| 7 | Used consistently and effectively |
|
||||
| 10 | Optimizing |
|
||||
|
||||
### More effective Agile Team Structure
|
||||
The focus is to have a *cross-functional* team with diverse expertise in different software domains such as front-end, back-end, architecture design, UX design, etc. A typical agile team requires at least the following specializations:
|
||||
- Developers from different layers of the application (front end, back end, etc) and with different expertise (architecture, user experience, security, etc)
|
||||
- Testers from different layers of the application
|
||||
- technical writers
|
||||
- experts in the development process being used (Scrum Master)
|
||||
- Subject Matter Experts (e.g. Industry experts)
|
||||
- Business experts who bring business understanding and ROI to the team (Product Owner)
|
||||
It is difficult to find a full set of skills and remain small (5-9 people), which is why some people might play multiple roles and the organization should help the members to build those skills.
|
||||
|
||||
Beyond skills **Ability and Authority** to make decisions should lie within the team in order for it to implement actual agile
|
||||
|
||||
Treat teams as *black boxes* where you only give inputs and receive outputs. The teams commit to a sprint goal that they will deliver, but the management should not care about how this is delivered. Managers should also not review minute and miniature details and not do micromanagement.
|
||||
### More effective Agile Team Culture
|
||||
Motivate teams through *Autonomy, Mastery, Purpose*. This principle comes from the psychologist Daniel Pink. Motivation always needs to be intrinsic and cannot be forced upon someone.
|
||||
**Autonomy** refers to the ability to direct your own life and work - what you do, when you do it and who you do it with. If a person doesn't believe their organization trusts them, thy won't believe they have real autonomy.
|
||||
**Mastery** refers to the desire to learn and improve, thus to the idea to constantly getting better. This is especially important for technical staff. The opportunity of growth has been a stronger motivator for developers than advancement, recognition, salary, status, level of responsibility and other factors.
|
||||
**Purpose** refers to understanding why what you're working on matters. What is the big picture? How it the thing you're working on more important than yourself? How does it support the company or the world at large?
|
||||
|
||||
Another important point is to consider not only the project in a business perspective, but also consider the team to be part of the project. If the team is energized after the project has finished, they have grown, and will be an asset to the company for future projects. If they are burnt out they won't be of any use after the project. As a company you should grow as well, so take care of your people.
|
||||
|
||||
Developing a business focus means putting every single developer in direct contact with customers. This helps them to see the big picture and will teach them to think through the lens of the customer instead of overly technical. Further it enhances the Purpose pillar of the developers, which increase motivation. Keep in mind that this should become / be a habit, not a one time thing.
|
||||
|
||||
Assigning clear team roles, improves the efficacy of teams.
|
||||
|
||||
### More Effective Distributed Agile Teams
|
||||
One of the key principles of distributed agile teams is to **tighten the feedback loop**, such that problems arise early and can be solved timely and effectively, which in turn allows the team to grow. In fact, a lot of suggestions in the book are about tightening the feedback loops: Product Owners are there to tighten the feedback loop around requirements, cross-functional teams with different skillsets allow for faster decision making, fast automated testing tightens the loop between coding and testing.
|
||||
Geographically distributed teams loosen the feedback loop because of:
|
||||
- non-ideal communication
|
||||
- time difference
|
||||
- larger batches of work before they are being shipped,
|
||||
- differences in languages
|
||||
- differences in culture
|
||||
- development and testing happening at different locations
|
||||
- product ownership and development at different locations
|
||||
- work on shared functionality 50/50
|
||||
|
||||
Once again, the goal is to have self-directed cross-functional teams that have the ability and the authority to make binding decisions locally.
|
||||
|
||||
#### Dos
|
||||
- **routine face-to-face communication (scheduled)**: most of the problems are miscommunication. Plan with visits every 6 weeks
|
||||
- **increase logistical support for distributed teams**: Scheduled meetings: make good meeting habits. Make sure all members have good devices (microphones, headsets, etc) and that a communication tool like slack is used. Consider using remote proxies, meaning someone at the remote office is responsible. Make sure to provide onboarding and training. Mentoring is also important.
|
||||
- **Leverage Autonomy, Mastery and Purpose**: Treat all offices equally, don't use terminology like main office, secondary office; onshore vs offshore, etc. This reduces the Autonomy, Mastery and Purpose of the offshore office. Each site should be able to perform work autonomously and be able to grow autonomously
|
||||
- **Respect Conway's Law**: Technical structure of a system reflects the structure of the human organization that built the system. This is a two-way street, meaning the system also influences the teams.
|
||||
- **Treat Agile teams as black boxes**: Don't focus on how the teams perform the work.
|
||||
- **Maintain high quality**: keeping software close to a releasable state minimizes the discrepancy across distributed teams
|
||||
- **Be aware of cultural differences**: willingness to communicate bad news or answering "no" to questions, response to authority, individual vs team accomplishment, work-hour expectations, work life balance.
|
||||
- **Inspect and Adapt**: regular retrospectives to assess what is working and what is not. Teams must be empowered to make the changes they identify as causes.
|
||||
|
||||
|
||||
> [!Important] Key Principle: Fix the System, Not the Individual
|
||||
> Increased miscommunication leads to errors, meaning people spend more time fixing defects. It is crucial to **decriminalize errors**, such that people embrace them and learn from them. Treat errors as *system errors* and not personnell problems.
|
||||
>
|
||||
> What is it about our system that allowed this error to occur?
|
||||
|
||||
### More Effective Individuals and Interactions
|
||||
|
||||
|
||||
### Enjoy the Fruits of Your Labor
|
||||
The agile mindset is about decriminalising mistakes and develop a Growth Mindset. Use mistakes as learning opportunities, Inspect and Adapt, and gradually become better.
|
||||
The main benefits for your organisation:
|
||||
- teams that stay focused on goals and that are responsive when things change
|
||||
- teams that monitor the effectiveness in order to replace ineffective practices with better ones meaning throughput increases over time
|
||||
- teams that monitor workflows. they will know where the work is and if it's progressing as it should. Increasing visibility and keeping delivery promises with high quality
|
||||
- teams work well with other teams and outside world
|
||||
- constant discoveries, but few disruptive surprises. If they appear you find them early and can react to them
|
||||
- high quality work at all times and identify opportunities for improvement. High motivation
|
||||
|
||||
#### Maturation Phases
|
||||
1. several sprints to learn scrum, learn small increment,
|
||||
2. over time focus shifts to organisations interaction with teams
|
||||
3. iteratively teams are transformed. They deliver quickly and change direction quickly, meaning the organization has strategic opportunities to plan and execute differently and better
|
||||
4. meaning everything gets better and better over time.
|
||||
|
||||
#### Summary of Key principles
|
||||
- **Inspect and Adapt**: Agile is empirical with focus on learning from experience. Meaning the framework should create opportunities to reflect periodically and make adjustments based on experience.
|
||||
- **Start with Scrum**: might not be the final journey, but is the best structured and best supported place to start.
|
||||
- **Build Cross-Functional Teams**: The teams should be self managed, meaning they need to include a full skillset to make well informed decisions that are binding to the organisation.
|
||||
- **Integrate Testers into the Development Team**: Close feedback loop between development and test by having the people work together.
|
||||
- **Motivate Teams Through Autonomy, Mastery, and Purpose**: Motivation factors are inherently supported: Teams work with Autonomy and to become better over time (Mastery). healthy Agile team and motivated Agile team are strongly intertwined.
|
||||
- **Develop a Growth Mindset**: Agile teams have a big steady focus on getting better.
|
||||
- **Develop Business Focus**: Developers should understand the business to fill the gaps in requirements.
|
||||
- **Tighten Feedback Loops**: Don't take any longer to learn lessons than you need to. This supports more rapid progress from Inspect and Adapt and faster imporvements in Effectiveness.
|
||||
- **Fix the System, Not the Individual**: If a developer is not performing look for the system problem that is frustrating the person. Usually it's the system, not the people.
|
||||
- **Increase Team Capacity by Building Individual Capacity**: Team attributes are the combination of individual members attributes and interactions. By strengthening the people, you strengthen the team.
|
||||
- **Keep Projects Small**: They are easier and more often successful. Not all work can be structured like this, but if you can you should do it.
|
||||
- **Keep Sprints Short**: they support a frequent inspect and adapt feedback loop and expose problems quickly before they grow into large problems
|
||||
- **Deliver in Vertical Slices**: Feedback is important and teams get better feedback on their product in vertical slices and thus improve more. This means the business improves more as well.
|
||||
- **Manage Technical Debt**: Focus on Quality. Managing technical debt supports higher team morale, faster progress and higher quality products.
|
||||
- **Support Large Agile Projects Through Architecture**: Good architecture even allows large projects to use agile. Good architecture can make a large project feel smaller
|
||||
- **Minimize the Defect Detection Gap**: The cost of fixing a defect grows with the age of the defect. --> Detecting early and fixing it is cheaper and increases quality.
|
||||
- **Create and Use a Definition of Done**: a good definition of done helps catch incomplete or faulty work early, minimizing the gap between defect insertion and detection.
|
||||
- **Maintain a Releasable Level of Quality**: High quality helps catching additional defects that slip through
|
||||
- **Use Automated Test, Created by the Development Team**: Helps minimizing the defect detection gap. Everyone on the team feels responsible and reinforces that quality is the responsibility of everyone.
|
||||
- **Refine the Product Backlog**: this ensures the team tackles high priority tasks first and doesn't invent new requirements
|
||||
- **Create and Use a Definition of Ready**: make sure requirements are truly ready before the team begins implementing them.
|
||||
- **Automate Repetitive Activities**: You have more benefits when automating repetitive tasks.
|
||||
- **manage to Outcomes, Not Details**: Leave autonomy with the team by communicating desired outcomes, not implementation details.
|
||||
- **Express clear purpose with commander's intent**: this leaves the team a clear ability to make timely, local decisions
|
||||
- **Focus on Throughput, Not Activity**: Busyness is not the objective, valuable work is.
|
||||
- **Model Key Agile Behaviours**: Effective leaders model the behaviours they want to see in others.
|
||||
- **Decriminalize Mistakes**: The goal is to surface mistakes as fast as possible without hesitation from the team so you can learn from them. A mistake you don't learn from penalizes the organisation twice.
|
||||
- **Plan Based on Measured Team Capacity**: Agile is an empirical approach: teams and organisations should plan their work based on their measured past performance.
|
||||
|
||||
---
|
||||
```query
|
||||
More Effective Agile Steve McConnell
|
||||
-file: "More Effective Agile by Steve McConnell.md"
|
||||
```
|
||||
@@ -0,0 +1,275 @@
|
||||
---
|
||||
title: Outlive by Peter Attia
|
||||
created_date: 2024-10-23
|
||||
updated_date: 2024-10-23
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
type: book
|
||||
book_name: Outlive
|
||||
author: Peter Attia
|
||||
status: read
|
||||
---
|
||||
# Outlive by Peter Attia
|
||||
- **🏷️Tags** : #10-2024 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
> [!info] Import Clippings from Kindle
|
||||
> Annotate Clippings with thoughts and cross references
|
||||
|
||||
|
||||
---
|
||||
## Notes
|
||||
### Medicine 2.0 vs Medicine 3.0
|
||||
Medicine 2.0 is reactive, only reacting to problems once they appear. Medicine 3.0 on the other hand is proactive, trying to do things today in order to delay or prevent problems in the future.
|
||||
![[image 2.jpg]]
|
||||
|
||||
Healthspan is the quality of life.
|
||||
Lifespan is the length of life.
|
||||
|
||||
#### Flaws of Medicine 2.0
|
||||
- helps us live longer with the disease
|
||||
- Looks at each disease separately (especially the four horsemen)
|
||||
- Diabetes is a major risk factor for cancer and Alzheimer‘s
|
||||
- All is related to the biological process of aging
|
||||
#### Goals of Medicine 3.0
|
||||
- look at all diseases at once. What can I do to reduce the risk of all of them significantly?
|
||||
-
|
||||
|
||||
#### The Four Horsemen
|
||||
Cardiovascular Disease
|
||||
Cancer
|
||||
Diabetes
|
||||
Neurodegenerative Disease
|
||||
|
||||
#### Healthspan
|
||||
Three vectors that span a space:
|
||||
1. Cognitive Health
|
||||
2. Physical Health
|
||||
3. Emotional Health
|
||||
|
||||
You can only be healthy if you are healthy in all three of those.
|
||||
|
||||
Maybe the following definition (my own idea)?
|
||||
Health = min(cognitive health, physical health, emotional health)
|
||||
|
||||
#### Objective -> Strategy -> Tactics
|
||||
Tactics are short term and precise plans on how to achieve a simple goal.
|
||||
Strategy on the other hand is the long term plan, without precise implementation to a complex problem.
|
||||
The boxing analogy: strategy: make better, fitter and younger boxer tired by provoking him and enduring minimal damage yourself until you can finish him because you have much more energy left.
|
||||
Tactic: provoke by hitting him in a very simple way ( you don’t hit a champion like that), tire him out by only dodging but not really attacking
|
||||
|
||||
—-
|
||||
Aging is a major risk factor for the four horseman, because your body is not equipped anymore to fight them off.
|
||||
|
||||
—-
|
||||
Our Strategy:
|
||||
- avoid the three pillars of Healthspan decline simultaneously
|
||||
- Focus on improving healthspan, the lifespan benefits are closely related and follow automatically. Also Lifespan is binary: you’re alive or dead, no qualitative measure
|
||||
- Understand the four horseman in detail, to know our strengths to fight against them
|
||||
|
||||
##### Tactics
|
||||
> In Medicine 3.0, our tactics must become interwoven into our daily lives. We eat, breathe, and sleep them - literally. By peter Attila
|
||||
- Exercise
|
||||
- Nutrition
|
||||
- Sleep
|
||||
- Emotional Health
|
||||
- Exogenous Molecules (drugs, hormones and supplements)
|
||||
|
||||
###### Exercise
|
||||
Breakdown because its a very broad term:
|
||||
- Strength
|
||||
- Stability
|
||||
- Aerobic Efficiency
|
||||
- peak Aerobic capacity
|
||||
|
||||
Exercise is the most important tactic: it benefits all pillars of healthspan:
|
||||
|
||||
|
||||
### Datadriven
|
||||
Sources
|
||||
- Observe Centenarians
|
||||
- Animal models (lab mice)
|
||||
- Human Studies of the four horsemen
|
||||
- how do they start?
|
||||
- Progress? What fuels them?
|
||||
- What underlying factors do they share?
|
||||
- What are the treatments used? And how can we infer tactics to do prevention?
|
||||
- We want to know them inside out
|
||||
- Studies of aging (human and animal)
|
||||
- Molecular and mechanistic
|
||||
- Drugs or exercise that fight against it
|
||||
- Mendelian Randomization:
|
||||
- what allels of a gene induce higher risks of a disease
|
||||
#### Centenarians
|
||||
- They shift the aging curve by 1-3 decades, but in the end they still often die of the four horseman. This can be interpreted as being younger at any stage in life.
|
||||
- They mostly are very healthy at ages above 100, scoring well in cognitive tests and daily tasks tests. This means their healthspan is still large
|
||||
- The older you get, the healthier you have been
|
||||
- 20-30% of the longevity might be explained by genes
|
||||
- We try to copy the phenotype despite not having their genotype
|
||||
- Old relatives indicate higher chance of getting old as well
|
||||
- Suffering stage at the end is very short
|
||||
|
||||
##### Genes
|
||||
Most of them do something in cholesterole or glucose metabolism
|
||||
1. APOE
|
||||
2. CETP
|
||||
3. APOC3
|
||||
4. FOXO3 (page 78)
|
||||
|
||||
What centenarians get with their genes we want to achieve otherwise, mostly through training and nutrition.
|
||||
|
||||
### Eat Less, Live Longer?
|
||||
#### Rapamycin
|
||||
- [ ] do research about rapamycin #todo/p
|
||||
|
||||
Also known as:
|
||||
- sirolimus as a coating of arterial stents.
|
||||
- Everolimus: kidney cancer
|
||||
|
||||
Rapamycin tends to slow down cellular growth and division. It works directly on a intracellular protein complex called mTOR (mechanistic Target Of Rapamycin).
|
||||
mTOR can be found nearly across all species of the planet, meaning it is very important, also for us. Rapamycin acts like a switch for mTOR.
|
||||
|
||||
##### mTOR
|
||||
It’s Job is to balance an organism’s need to grow and reproduce against the availability of nutrients. When food is plentiful, mTOR is activated and the cell goes into growth mode (create new proteins and cell division). When the nutrients are scarce mTOR is supressed and the cell goes into a recycling mode, breaking down unused cellular components and cleaning the house
|
||||
|
||||
##### Slowdown of Aging in Mice
|
||||
In 2009 a study was published where rapamycin was used to extend life of mice - 13% for females, 9% for males. And the study was experimentally repeated across the globe by other groups.
|
||||
|
||||
This did not really come as a surprise, because rapmycin has the same effect as eating less (suppressing mTOR). And it had already been shown countless times that eating less results in longer lives for lab animals. The first person to document the process was Alvise Cornaro in the 16th century.
|
||||
|
||||
##### Caloric Restriction (CR)
|
||||
Experiment where one group can eat whatever whenever they want. The CR group gets all the nutrients needed for life, but 20-30% fewer total calories. Good results across the studies (15-45% longer lives and remarkably healthier animals).
|
||||
For us this probably does not apply as a strategy, because it is difficult to do it over a long timespan and you might be more susceptible to infections and other diseases, because you are not in a safe lab environment.
|
||||
|
||||
##### Cellular Aging
|
||||
|
||||
### 10 - Thinking Tactically
|
||||
> Absorb what is useful, discard what is useless, and add what is specifically your own.
|
||||
> - Bruce Lee
|
||||
|
||||
Orientation Questions:
|
||||
1. are you over- or undernourished (calorie count)?
|
||||
2. undermuscled or adequately muscled?
|
||||
3. Metabolically healthy or not?
|
||||
|
||||
What would I say about myself?
|
||||
1. slightly over
|
||||
2. undermuscled (okay VO2 max and endurance)
|
||||
3. I think yes
|
||||
|
||||
|
||||
### 11 - Centenarian Decathlon
|
||||
This chapter helps patients to define their own goals towards building an exercise routine and willpower now by visualizing tasks and passions as a 90 year old.
|
||||
- [ ] #todo/p copy list of examples from book
|
||||
|
||||
- 1 min dead hang
|
||||
### 12 - Training 101
|
||||
|
||||
> It is impossible to produce superior performance unless you do something different from the majority.
|
||||
> - Sir John Templeton
|
||||
|
||||
|
||||
#### Cardio
|
||||
Includes low power endurance (Zone 2) as well as maximal aerobic effort (VO2 max).
|
||||
|
||||
##### Aerobic Efficiency: Zone 2
|
||||
Glucose and fatty acids can be the fuel for our muscles. There are several metabolic pathways for glucose but only microcosms can convert fatty acids into energy.
|
||||
Zonte 2 exercise is mostly done by our slow twitch muscle fibers ( type 1). They are extremely dense with microcomputers and can therefore metabolize fat very well. When the pace increases, more and more type 2 muscle fibers start to join the effort. This are less efficient and more forceful and produce way more lactate because of a different way of producing ATP. When lactate turns into lactic acid you feel the muscle burning.
|
||||
Zone 2 can also be defined by the maximum effort without accumulating lactate.
|
||||
|
||||
##### VO2 Max
|
||||
VO2 max describes the maximum output of our body.
|
||||
|
||||
![[image 9.jpg]]
|
||||
|
||||
|
||||
|
||||
#### Strength
|
||||
Steady decline of muscle mass, muscle strength and muscle speed starting in your thirties. It’s hard to gain muscle when you’re older, but possible to keep it when you already have it.
|
||||
Accidents, diseases and other breaks in training leads rapidly to muscle loss. This is why it’s crucial not to get injured.
|
||||
|
||||
Bone density diminishes on a parallel path to the muscle. We care about this because we want to slow down this decline.
|
||||
Strategy to fight against:
|
||||
1. Optimize nutrition, focusing on protein and total energy needs (see nutrition chapters).
|
||||
2. Heavy loading-bearing activity. Strength training, especially with heavy weights, stimulates the growth of bone-more than impact sports such as running (though running is better than swimming/cycling).
|
||||
Bones respond to mechanical tension and estrogen is the key hormone in mediating the mechanical signal (weight bearing) to a chemical one telling the body to lay down more bone.
|
||||
3. HRT, if indicated.
|
||||
4. Drugs to increase BMD, if indicated.
|
||||
|
||||
Rucking is a sport where you hike with a heavy pack. Helps bone density growth as well as cardiovascular training and strength training for legs and trunk.
|
||||
|
||||
Focus strength training:
|
||||
1. Grip strength
|
||||
2. Concentric and eccentric movement
|
||||
3. Pulling motion ( rows and pull ups)
|
||||
4. Hip-hinging movements (dead lifts)
|
||||
|
||||
#### Stability
|
||||
This is the solid foundation that prevents us from getting injured. Stability makes us bulletproof.
|
||||
|
||||
By sitting in Chairs all the time we forgot the optimal way of moving our bodies. Thats the theory of DNS (Dynamic Neuromuscular Stabilization).
|
||||
|
||||
- www.rehabps.com
|
||||
- Www.posturalrestoration.com
|
||||
|
||||
##### Breathing
|
||||
Breathing is the foundation of stability.
|
||||
- Mr. Stay Puft
|
||||
- Sad Guy
|
||||
- Yogini
|
||||
|
||||
|
||||
### 15 Putting Nutritional Biochemistry into Practice
|
||||
|
||||
#### Macro nutrients
|
||||
##### Alcohol
|
||||
##### Carbohydrates
|
||||
The goal is to keep average glucose below 100 mg/dl with standard deviation of less than 15 mg/dl ( corresponds to HbA1c of 5.1%).
|
||||
##### Protein
|
||||
Its the one macronutrient you shouldn’t ignore. Its the only one where there is a recommendation of 0.8g per kg of body mass. But if you want to maintain muscle you should eat double to triple (1.6-2.2 g/kg). For me with 80 kg this is 120-180 g.
|
||||
Make sure to include all the essential amino acids in your diet, especially leucine, lycine (3-4g per day) and methionine (1g per day). If you want to increase mass, you need 2-3g per serving, four times a day of leucine.
|
||||
|
||||
### Notes and Thoughts
|
||||
- easy biomarker test device to use at home (like theranos?) #idea/startup
|
||||
|
||||
#### Actionpoints
|
||||
- [ ] Healthcheck with biomarker analysis: what is ideal (not normal) #todo/p ⏫
|
||||
- [ ] Understand mendelian randomization #todo/p
|
||||
- [ ] Study the four horseman in detail to understand the biological process underneath #todo/p
|
||||
|
||||
|
||||
|
||||
---
|
||||
### Erste Reaktion
|
||||
Ich habe heute das Buch fertig gelesen. Die letzten Kapitel waren sehr Praxis orientiert. Insgesamt bin ich begeistert davon wie Peter Attia das Buch aufbaut und bin grundsätzlich überzeugt von seiner Herangehensweise ans Gesund leben.
|
||||
Vor allem das er emotionale Gesundheit als gleich wichtig oder sogar als wichtiger betrachtet als körperliche Gesundheit finde ich faszinierend. Logisch übertreibt er gewisse Punkte und Geschichten aus seinem eigenen Leben. Es bringt mich jedoch dazu selber über mein Leben und meinen Zustand zu reflektieren. Wie ist meine emotionale Gesundheit? Ich glaube momentan nicht die beste.
|
||||
|
||||
|
||||
Definition Alter: wenn man in die Zukunft denkt ist man jung, wenn man in der Vergangenheit denkt ist man alt.
|
||||
|
||||
---
|
||||
## Cross References
|
||||
```query
|
||||
Outlive Peter Attia
|
||||
-file: "Outlive by Peter Attia.md"
|
||||
```
|
||||
@@ -0,0 +1,728 @@
|
||||
---
|
||||
title: Software Project Survival Guide by Steve McConnell
|
||||
created_date: 2025-01-07
|
||||
updated_date: 2025-01-07
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
type: book
|
||||
book_name: Software Project Survival Guide
|
||||
author: Steve McConnell
|
||||
status: not_started
|
||||
---
|
||||
# Software Project Survival Guide by Steve McConnell
|
||||
- **🏷️Tags** : #01-2025 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
- We should define exact goals that are measurable: What does the software need to do? What's its accuracy?
|
||||
---
|
||||
## Clippings
|
||||
### Intro
|
||||
- Software projects fail because of
|
||||
- lack of knowledge of software project conduct
|
||||
- lack of resolve --> indecisiveness, procrastination, low confidence, inconsistency
|
||||
- References
|
||||
- Key Practices of the Capability Maturity Model, Version 1.1 by Software Engineering Institute (SEI)
|
||||
- Recommended Approach to Software Development, Revision 3 by NASA Software Engineering Laboratory (SEL)
|
||||
### The Survival Mindset
|
||||
- The only outcome considered a failure is total collapse
|
||||
- Success: meet cost, schedule and quality goals within engineering tolerances (+- 10% of goal)
|
||||
- **Survival Needs**
|
||||
- Needs that need to be satisfied before anything else can work (humans: food, shelter, water, air)
|
||||
- project not canceled, team not fired, adequate physical working conditions
|
||||
- meeting personal promises for schedule and functionality
|
||||
- Project team must be satisfied that the project can be completed *at all* before it can worry about the schedule or budget
|
||||
- ![[Pasted image 20250107095858.png]]
|
||||
- Individual developers might not prioritise the same needs as the software projects survival needs
|
||||
#### Stakeholders
|
||||
Each group involved in the project must respect the rights of the other parties. And each group's survival needs must be thoroughly satisfied such that they can focus on higher level needs. Usually this is the *Customer* and the *Project Team*:
|
||||
##### Customer's Bill of Rights
|
||||
1. To set objectives for the project and have them followed
|
||||
2. To know how long the software project will take and how much it will cost
|
||||
3. To decide which features are in and which are out of the software
|
||||
4. To make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes
|
||||
5. To know the project's status clearly and confidently
|
||||
6. To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems
|
||||
7. To have ready access to project deliverables throughout the project
|
||||
##### Project Team's Bill of Rights
|
||||
1. To know the project objectives and to clarify priorities.
|
||||
2. To know in detail what product I'm supposed to build and to clarify the product definition if it is unclear.
|
||||
3. To have ready access to the customer, manager, marketer, or other person responsible for making decisions about the software's functionality.
|
||||
4. To work each phase of the project in a technically responsible way, especially to not be forced to start coding too early in the project.
|
||||
5. To approve effort and schedule estimates for any work that Team will be asked to perform. This includes the right to provide only the kinds of cost and schedule estimates that are theoretically possible at each stage of the project; to take the time needed to create meaningful estimates; and to revise estimates whenever the project's requirements change.
|
||||
6. To have my project's status reported accurately to customers and upper management.
|
||||
7. To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project.
|
||||
|
||||
#### Survival Check
|
||||
This tool is a quick check to verify that the essential characteristics for the survival are met. In the book a 👍🏼 or a 💣 is used. We will use a box just like below for every chapter.
|
||||
|
||||
|
||||
> [!question] Survival Check - Survival Training
|
||||
> - 👍🏼 Project team's survival needs are being met
|
||||
> - 👍🏼 The customer and the project team agree to respect each other's software project rights
|
||||
> - 💣 The agreement in principle is not followed in practice
|
||||
|
||||
|
||||
### Software Project Survival Test
|
||||
The idea of the survival test is to check the chances of survival of a project in different stages and to act upon the neglected areas if needed.
|
||||
There is a list of questions that will be answered with 0-3 points, 3 being fully qualified.
|
||||
The questions are separated into the following categories
|
||||
- Requirements
|
||||
- Planning
|
||||
- Project Control
|
||||
- Can progress be tracked and viewed by team members?
|
||||
- defect tracking, source control, project management software
|
||||
- Risk Management
|
||||
- up to date list of risks to the project
|
||||
- Personnel
|
||||
- Do we have all technical expertise?
|
||||
- Are there enough team members and are they committed?
|
||||
-
|
||||
|
||||
Most projects have a score <50.
|
||||
|
||||
| **Score Range** | **Rating** | **Description** |
|
||||
| --------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 90+ | Outstanding | A project with this score is virtually guaranteed to succeed in all respects, meeting its schedule, budget, quality, and other targets. In terms of Chapter 1's project needs hierarchy, such a project is fully "self-actualized." |
|
||||
| 80-89 | Excellent | A project at this level is performing much better than average. Such a project has a high probability of delivering its software close to its schedule, budget, and quality targets. |
|
||||
| 60-79 | Good | A score in this range represents a better-than-average level of software development effectiveness. Such a project stands a fighting chance of meeting either its schedule or its budget target, but it probably won't meet both. |
|
||||
| 40-59 | Fair | This score is typical. A project with this score will likely experience high stress and shaky team dynamics, and the software will ultimately be delivered with less functionality than desired at greater cost and with a longer schedule. This kind of project stands to experience the greatest benefit from applying the plan described in this book. |
|
||||
| < 40 | At Risk | A project with this score has significant weaknesses in the major areas of requirements, planning, project control, risk management, and personnel. The primary concern of a project in this category should be whether it will finish at all. |
|
||||
|
||||
> [!question] Survival Check - Survival Test
|
||||
> - 👍🏼 Project scores at least 60 on the Survival Test
|
||||
> - 👍🏼 The project scores less than 60, but corrective actions are planned to improve its score.
|
||||
> - 💣 The project team doesn't follow through on the planned corrective actions.
|
||||
|
||||
### Survival Concepts
|
||||
|
||||
> [!Quote]
|
||||
> An investment made in process at the beginning of the project produces large returns later in the project
|
||||
|
||||
Processes are important because they make the development more productive and resistant in the long term. Example processes are:
|
||||
- formally write down requirements
|
||||
- use a procedure to control additions and changes to the requirements
|
||||
- Do reviews of all requirements, designs and source code
|
||||
- Develop a written *Quality Assurance Plan*, including a *test plan*, *review plan* and a *defect tracking plan*.
|
||||
- Create an *implementation plan* that defines in which order the components are developed.
|
||||
- Automated source code control (e.g. git)
|
||||
- Revise Cost and schedule after each milestone
|
||||
|
||||
If teams do not invest in process at the beginning of the project, the amount of time spent for process and thrashing (i.e. unproductive time) will increase (see Figure 3-3).
|
||||
![[Pasted image 20250107114628.png]]
|
||||
|
||||
On the contrary, teams which establish processes in the beginning (overhead) will spend less and less time on thrashing and processes as the project moves on.
|
||||
![[Pasted image 20250107114616.png]]
|
||||
|
||||
|
||||
> [!Quote] Overhead of a cancelled Project
|
||||
> If you think that attention to process is needless overhead, consider that the overhead of a canceled project is 100 percent.
|
||||
|
||||
|
||||
> [!warning] Opposite Views
|
||||
> - Processes limit developer's creativity
|
||||
> - --> Set up an environment where creativity is still possible.
|
||||
> - Developers feel best in environments where they are the most productive.
|
||||
> - Research shows that in regulated environments people feel more productive.
|
||||
|
||||
#### Upstream and Downstream
|
||||
Upstream contains all early work of a project, such as requirements definition and architecture design. Downstream refers to later parts such as construction and system testing.
|
||||
Defects cost more (50-200 times more), the earlier in the project they are inserted as illustrated in the figure below.
|
||||
![[Pasted image 20250107120429.png]]
|
||||
Please note that the cost grows exponentially, which multiplies the effect.
|
||||
|
||||
> [!Quote]
|
||||
> Successful project teams create their own opportunities to correct upstream problems by conducting thorough, careful reviews of requirements and architecture.
|
||||
|
||||
Remember that just because no code is being written in the beginning that doesn't mean it is delaying the real work, but rather it is laying the groundwork for the project's success.
|
||||
Erring on the side of too much process is marginally more expensive, versus erring on too little process can be way more expensive (50-200x) in the long run. This is because of the *cone of uncertainty*, which illustrates that upstream decisions affect downstream decisions, but not vice-versa.
|
||||
![[Pasted image 20250107121222.png]]
|
||||
|
||||
|
||||
> [!Quote]
|
||||
> Early in the project you can have firm cost and schedule targets or afirmfeature set, but not both.
|
||||
|
||||
> [!question] Survival Check - Survival Test
|
||||
> - 👍🏼 Project leadership understands the critical role of well-defined processes and supports them.
|
||||
> - 👍🏼 The project's processes are generally oriented toward detecting as many problems upstream as possible.
|
||||
> - 👍🏼 Project leadership recognises that estimates made during the first half of the project are inherently imprecise and will need to be refined as the project progresses.
|
||||
|
||||
### Survival Skills
|
||||
Software projects are inherently complex and therefore need to be planned, controlled and made sure that the progress is visible, people are supported to do the project's work.
|
||||
The risks should be tracked and constantly redeveloped.
|
||||
#### Planning
|
||||
- Think about processes in the upstream period of fixing mistakes at 1/200th of the price.
|
||||
- Rule of thumb: each day spent in processes (e.g. technical review) saves 3-10 days later in the project
|
||||
- Software Development Plan
|
||||
- Project Estimates
|
||||
- Revised Estimates
|
||||
- Quality Assurance Plan
|
||||
- Staged Delivery Plan
|
||||
- Requirements Development
|
||||
- Architecture
|
||||
- Detailed Design
|
||||
|
||||
|
||||
> [!Important]+ Planning Checkpoint Review
|
||||
> Very early in the project (at about 10%) success or failure is determined. This means it can be used as a checkpoint to do a *go/no go* decision about the project. At this point the team should have produced:
|
||||
> - user interface prototype (and shown it to users)
|
||||
> - detailed requirements
|
||||
> - detailed project plan including cost and schedule estimates.
|
||||
>
|
||||
> **Mandatory Documents needed for the checkpoint**:
|
||||
> - Name of project's key decision maker
|
||||
> - Vision statement
|
||||
> - Business case for the software
|
||||
> - preliminary effort and schedule goals
|
||||
> - preliminary effort and schedule estimates
|
||||
> - top 10 risks list
|
||||
> - User interface Style Guide
|
||||
> - Detailed User interface Prototype
|
||||
> - User Manual / Requirements Specification
|
||||
> - Software Quality Assurance Plan
|
||||
> - Detailed Software Development Plan
|
||||
>
|
||||
> **Agenda for the Checkpoint Review**
|
||||
> - Is the original product concept still viable?
|
||||
> - Will it be possible to develop a product that matches the project's vision statement?
|
||||
> - Is the business case for the software still justified when updated, more accurate cost and schedule estimates are considered?
|
||||
> - Can the major risks to the project be surmounted?
|
||||
> - Have users and developers been able to agree on a detailed User Interface Prototype?
|
||||
> - Is the User Manual / Requirements Specification complete and stable enough to support further development work?
|
||||
> - Is the Software Development Plan complete and adequate to support further development work?
|
||||
> - What is the estimated cost of completing the project
|
||||
> - What is the estimated schedule for completing the project?
|
||||
|
||||
Benefits of splitting development into these two funding phases:
|
||||
1. Cancelling one bad project at the stage of 10-20% can fund many other projects
|
||||
2. More reliable funding for the bulk of the project, because it can be better estimated
|
||||
3. Forces project manager to do upstream work in the first 10-20% --> setting the project up for success.
|
||||
#### Risk Management
|
||||
You can hope for the best but should prepare for the worst --> risk management.
|
||||
Typical risks:
|
||||
- failure to plan
|
||||
- failure to follow the plan that has been created
|
||||
- failure to revise the plan when project circumstances change
|
||||
|
||||
Software development is a high-risk activity, which is why it is essential to perform risk managment.
|
||||
|
||||
> [!Quote] By Tom Gilb
|
||||
> If you don't actively attack the risks on a software project, they will actively attack you.
|
||||
|
||||
#### Project Control
|
||||
Without project control every project is *out of control*, which is definitely something we do not want. We do not want to control the people, but rather the project itself:
|
||||
- Choose a software lifecycle model (e.g. staged delivery) to provide a framework
|
||||
- requirements change management --> only update what is necessary
|
||||
- Design and coding standards, to have consistency
|
||||
- write detailed plan of project to align developer's work with goals and to minimize conflicts in between developers
|
||||
#### Project Visibility
|
||||
The visibility is the ability to determine a project's true status, which will give answers to questions like:
|
||||
- Is the project on track to achieve goals?
|
||||
- Are we within 10% of budget and schedule or only within 50%?
|
||||
|
||||
Good visibility does not come automatically, you have to plan for it!
|
||||
|
||||
Activities that help achieve visibility:
|
||||
- Vision Statement
|
||||
- Hold a planning checkpoint review after 10% of the project
|
||||
- Regularly compare actual performance against planned performance to check if plan is working and adapt if necessary.
|
||||
- Use binary milestones: they are either done or not done
|
||||
- Drive the project to a releasable state periodically to show project's true condition
|
||||
- revise estimates after each phase to improve planning with more information
|
||||
#### Peopleware
|
||||
The development team needs to be on board in order for the project to succeed. Guidelines to consider the human aspect in software development:
|
||||
- Align Developers' Interest with Work Assignments:
|
||||
- Make work *interesting*
|
||||
- Make *possible goals*: developers usually are realistic and are demotivated by goals that are out of reach
|
||||
- Show developers that you sincerely appreciate them
|
||||
- don't use cheerleading campaigns, impossible challenges or monetary rewards
|
||||
- Provide Thinking-oriented office space
|
||||
- the process is one of continuous discovery and invention --> create atmosphere which is supportive.
|
||||
- Space where developers can concentrate
|
||||
- Avoid open work bays
|
||||
- allows deep concentration
|
||||
- install soda machine or hang out zone for when they don't need to concentrate to foster communication and inspirational discussions.
|
||||
|
||||
#### User Involvement
|
||||
Don't assume you know what the user wants! Marketers want too many features such that the essential features cannot be found anymore, Developers create technical features that user's don't care about.
|
||||
- Ask users what they want, show them what they intend to build and ask how they like it. Then listen carefully until you fully understand the stated and unstated elements of the users' reponses
|
||||
- Identifying who the user is might be difficult
|
||||
- user needs to be open to mock-ups (very crude prototype)
|
||||
- Adopt easy features and changes immediately and implement larger more complicated changes later on.
|
||||
|
||||
User involvement saves time because it eliminates a large source of requirement changes: features that no-one needs.
|
||||
|
||||
#### Product Minimalism
|
||||
Focus on simplicity. Simple solutions are always better than complicated ones.
|
||||
- Focus on taking away components of the software to make it simpler, rather than adding elements to make it more complex.
|
||||
|
||||
#### Focus on Shipping Software
|
||||
A company makes money by *shipping* software *not by developing* it!
|
||||
|
||||
|
||||
> [!question] Survival Check - Survival Skills
|
||||
> - 👍🏼 Project Team creates a detailed written plan, designed to eliminate potentially costly problems early in the project.
|
||||
> - 👍🏼 Project emphasizes the importance of upstream work holding a *Planning checkpoint review* to make a go / nogo decision when the project is about 10 percent complete.
|
||||
> - 👍🏼 Project practices active risk management
|
||||
> - 👍🏼 project plan emphasizes visibility and control
|
||||
> - 👍🏼 project plan involves real users early and throughout the journey
|
||||
> - 👍🏼 project is conducted in a productive environment
|
||||
> - 👍🏼 project plan calls for a simple-to-complex approach rather than the reverse.
|
||||
|
||||
### Successful Project at a Glance
|
||||
- source code tends to grow in a S-shaped curve where most of the code is written in the middle third of the project.
|
||||
- Staged delivery: ship important functionality fist
|
||||
- keep tabs on clearly defined milestones and deliverables
|
||||
|
||||
#### Intellectual Phases
|
||||
Different phases of a project have different characteristics. They need to overlap somehow, but we don't want them to overlap too much either.
|
||||
![[Pasted image 20250108151953.png]]
|
||||
|
||||
#### Project Flow
|
||||
**Staged delivery!**
|
||||
We want to ship staged versions of the software continuously in order to deliver something that works and improve upon it (ideally with more user feedback).
|
||||
Each stage is released after detailed design, coding, debugging and thorough testing.
|
||||
##### Benefits of Staged Delivery
|
||||
1. Critical functionality is available earlier:
|
||||
Because it is usually in the first deliverables.
|
||||
2. Risks are reduced early:
|
||||
at each stage we have the integration of the different parts which means that different parts of the software are continuously brought onto the same page. You also create tangible signs of progress at frequent intervals.
|
||||
3. Problems become evident early:
|
||||
You get frequent progress reports which show critical problems that can be addressed early. You will also see if the development team struggles, if they miss the deadline for the first deliverables.
|
||||
4. Status-reporting overhead is reduced:
|
||||
Shipped and working software is a more accurate status report than a paper report.
|
||||
5. Makes More Options Available: you have releasable software at all times, meaning if you want to release something is is much less work than if you don't
|
||||
6. Reduces possibility of estimation error: each delivery is a syncronizing event because you can compare the estimates with what is delivered and improve your estimation skills.
|
||||
7. Balances Flexibility and Efficiency: It avoids a situation like [[analysis paralysis]], because you can ship a small stage efficiently.
|
||||
##### Cost of Staged Delivery
|
||||
- You need to retest software at every stage
|
||||
- You need to execute merging and other version control tasks
|
||||
- You need to manage different versions
|
||||
- You need to plan the staged deliveries
|
||||
|
||||
Some of those costs are just exposed earlier in the process and would remain hidden (but still exist) otherwise.
|
||||
|
||||
#### Project Phases
|
||||
The phases described above slightly overlap, which is inevitable and desirable.
|
||||
![[Pasted image 20250108155841.png]]
|
||||
|
||||
|
||||
##### Distribution of Effort
|
||||
![[Pasted image 20250108160138.png]]
|
||||
|
||||
![[Pasted image 20250108160308.png]]
|
||||
|
||||
Note that e.g. requirements development requires 12% of the time, but only 6% of the effort, because it is less tangible and requires deeper contemplation such that it is done at a slower pace. This also means that it doesn't produce a lot of code.
|
||||
|
||||
##### Milestones and Deliverables
|
||||
Use lists from book pages 65ff.
|
||||
|
||||
|
||||
> [!question] Survival Check - Successful Project at a Glance
|
||||
> - 👍🏼 Project uses a staged delivery approach
|
||||
> - 👍🏼 Upper management, customer or both track progress by code growth curve
|
||||
> - 👍🏼 Upper management, customer or both track progress by keeping tabs on major milestones and deliverables
|
||||
|
||||
### Hitting a moving target
|
||||
#### Change Control
|
||||
[[Floris]] is no fan of change control, and the book explains why: he could have any changes made at any time before, with change control there is a process which needs to be followed.
|
||||
|
||||
> [!Quote]
|
||||
> People who are used to getting their way can still get their way with systematic change control, but they'll have to do it through a process that emphasizes visible decision making and accountability.
|
||||
|
||||
Change control only works if all parties accept the decision of the change control board.
|
||||
|
||||
> [!question] Survival Check - Change Control
|
||||
> - 👍🏼 The project has a change board.
|
||||
> - 💣 The change board's decisions can be reversed by management, marketing, or the customer.
|
||||
> - 👍🏼 The project has a written, approved Change Control Plan.
|
||||
> - 💣 Project team members aren't given enough time to carry out the plan.
|
||||
> - 💣 Work products aren't actually put under change control.
|
||||
> - 👍🏼 Change Proposals are evaluated by all the project's concerned parties before they are resolved.
|
||||
> - 👍🏼 The change board notifies the project's concerned parties of how each Change Proposal is resolved.
|
||||
> - 👍🏼 The change board has the project team evaluate changes in batches so that the team is not distracted by a constant barrage of change requests.
|
||||
|
||||
|
||||
### Preliminary Planning
|
||||
- Define project vision
|
||||
- identify executive sponsor
|
||||
- set targets
|
||||
- manage risks
|
||||
- map out strategies for using personnel
|
||||
|
||||
This all goes into a **software development plan**.
|
||||
|
||||
#### Project Vision
|
||||
Effective teams have a common vision and thus a clear understanding of the objective. Having a common vision aligns team members to work effectively together and avoiding time-wasting side trips.
|
||||
- Vision builds trust among team members because they know they work towards the same goal
|
||||
- An effective vision can have a motivating effect --> therefore it needs to be elevating
|
||||
- It needs to be achievable within the specified time frame
|
||||
|
||||
The vision should not promise too much (e.g. short schedule, low cost and rich functionality) since developers are realists and feel fooled with impossible goals.
|
||||
##### Deciding What to leave out
|
||||
Statements like creating the world's best of something include too much and therefore not provide much guidance to the development team. A good, exclusive vision statement helps the project team achieve the goal of software minimalism, which is essential for keeping project risk to a manageable level.
|
||||
##### Committing to the vision
|
||||
Formalize through a written vision statement and have it signed by every team member. Then put it under change control! It is the top most guidance element for the team and should be remembered often.
|
||||
#### Executive Sponsorship
|
||||
Make sure that the decision making comes from a single, clear authority (can be a board). Else decisions from different people do not align with each other and interfere and therefore slow down the entire project.
|
||||
|
||||
#### Project Scope Targets
|
||||
This is the envisioned schedule, budget, staffing and feature set to get started with. When development starts and you realize that desired features are not in line with schedule and buget you adjust one or the other.
|
||||
|
||||
|
||||
> [!Quote]
|
||||
> The best organizations plan to reestimate regularly throughout a project and periodically adjust their project plans based on the reestimation.
|
||||
|
||||
Put reestimation points in your plan (just as NASA does, see page 90):
|
||||
|
||||
| Estimation Point | Upper Limit | Lower Limit |
|
||||
|----------------------------------------------|-------------|-------------|
|
||||
| End of requirements definition and specification | x2.0 | x0.50 |
|
||||
| End of requirements analysis | x1.75 | x0.57 |
|
||||
| End of preliminary design | x1.4 | x0.71 |
|
||||
| End of detailed design | x1.25 | x0.80 |
|
||||
| End of implementation | x1.10 | x0.91 |
|
||||
| End of system testing | x1.05 | x0.95 |
|
||||
#### Publicizing Plans and Progress
|
||||
Involve the team in the planning phase, because the people who actually do the work often consider all details. If a plan cannot be followed because of wrong planning, it will not be followed and thus the team runs out-of-control.
|
||||
- [ ] Get the plans reviewed and approved by the developers
|
||||
|
||||
The team needs effective coordination of activities from the project manager, such that efforts are not wasted. Therefore its smart to get the plan approved by the team before the bulk of the work gets started.
|
||||
##### Progress Indicators
|
||||
Once the project started we have the following indicators to show how well we follow the plan. This creates project visibility.
|
||||
- List of tasks completed
|
||||
- Defect statistics
|
||||
- Top 10 Risks List
|
||||
- Percent of schedule used
|
||||
- percent of resources used
|
||||
- project management's status reports to upper management
|
||||
|
||||
- [ ] Create a project intranet homepage (confluence page) with links to planning, tracking, technical work products and project deliverables. Essentially make a dashboard (see page 93)
|
||||
|
||||
#### Risk Management
|
||||
The goal is to trade small amounts of increased overhead for large amounts of risk reduction.
|
||||
In order to commit to risk management:
|
||||
- Describe a risk management approach in writing
|
||||
- Budget funds for risk resolution and risk removal
|
||||
- Use risk assessments to update project plans, else all is for nothing
|
||||
|
||||
Tools for risk management:
|
||||
- Planning for risk management
|
||||
- Assign a risk officer
|
||||
- play devil's advocate during planning meetings and planning reviews
|
||||
- needs to have a bit of the attitude: "It will never work"
|
||||
- senior developer or senior tester
|
||||
- top 10 risk list
|
||||
-
|
||||
- risk-management plan for each risk
|
||||
- create anonymous risk-reporting channel
|
||||
- Bad news are not shared easily --> make it anonymous to facilitate. It is crucial that all team members do communicate this
|
||||
|
||||
> [!Idea] Use Jira / Github Issues for risk Tracking
|
||||
> This makes risks visible. People can discuss risks. You can assign responsibility for risk mitigation
|
||||
|
||||
##### Risk Management Plans
|
||||
Answer the following questions for every risk:
|
||||
- **Why?** Why is a risk-management plan needed for this specific risk? Describe the risk's probability of occurrence, consequences, and severity.
|
||||
- **How?** How will the risk be resolved in general? Describe the general approach to re- solving the risk. List or describe the options that were considered.
|
||||
- **What?** What specific steps will be taken to resolve the risk? List the specific steps and deliverables that will be generated in addressing the risk. Include a description of the conditions under which the risk will be upgraded— for example, if the risk cannot be resolved by a specific date.
|
||||
- **Who?** Who will be responsible for completing each step? List the specific person re- sponsible for completing each step.
|
||||
- **When?** When will each step be completed? List the completion date for each step.
|
||||
- **How much?** How much budget is allocated to the resolution of the risk? List the cost of each step that will be taken to resolve the risk.
|
||||
|
||||
#### Personnel Strategies
|
||||
- evaluate managers based on how well they retain project personnell
|
||||
- professional growth opportunities during the project
|
||||
- after the project team members should feel better about the company, not worse
|
||||
|
||||
|
||||
> [!Quote] Available vs Good
|
||||
> It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive.
|
||||
|
||||
Team dynamics and team bond play a more important role than individual developers' capabilities (slightly behind). This means we need to hire someone who fits into the team.
|
||||
|
||||
##### Key Staff-Buildup Questions
|
||||
- Does the project manager have software experience with one or more projects of a similar size?
|
||||
- Does project's senior technical staff have knowledge of the kind of software being built and experience on similar successful projects?
|
||||
- Most teams are comprised of average personnel. Do expectations about the team's productivity match the team members' abilities?
|
||||
- Will the individuals work well together?
|
||||
|
||||
##### Project Team Organization
|
||||
- **Project manager:** orchestrate detailed technical work (development, quality assurance, user documentation). Develops software development plan. Is the team's link to upper management.
|
||||
- **Product manager:** Business level work: marketing, product packaging, end-user documentation, end-user support. In-house projects: work with groups that use the system to define the software, setup training and user support.
|
||||
- **Architect:** Responsible for conceptual integrity at design and implementation level.
|
||||
- **User-interface designer:** responsible for conceptual integrity of software visible to end-user.
|
||||
- **End-user liaison:** interact with end-user throughout the project. Walk them through the prototype, demonstrate new releases, gather user feedback.
|
||||
- **Developer:** detailed design and implementation of software. Responsible for making the software work.
|
||||
- **QA/Testers:** responsible for Quality Assurance and test activities. Create detailed test plans and perform tests. Find all the ways to break the software.
|
||||
- **Tool smith:** Responsible for developing build scripts, maintain versioning system, developing utilities needed by the project.
|
||||
- **Build coordinator:** responsible for maintaining and running the daily build and notifying the developers when something breaks the build.
|
||||
- **Risk officer:** watch for emerging risks and diversion from the development plan.
|
||||
- **End-user documentation specialists:** generate help files, documentation, and instructional materials that end-users will use.
|
||||
|
||||
> [!important] Mixing Roles is Okay except for ...
|
||||
> ... Quality Assurance and Development
|
||||
|
||||
#### Time Accounting
|
||||
Tracking where team members spend their time will help with future planning.
|
||||
|
||||
|
||||
> [!question] Survival Check - Preliminary Planning
|
||||
> - 👍🏼 The project has a clear vision.
|
||||
> - 💣 The vision doesn't provide guidance in deciding what to leave out of the software.
|
||||
> - 👍🏼 The project team has identified an executive sponsor or committee with final authority over projectwide decisions.
|
||||
> - 👍🏼 The project plans and progress compared to the plans are readily available to all project team members and upper management.
|
||||
> - 👍🏼 The project has a risk officer.
|
||||
> - 💣 The risk officer is the project manager.
|
||||
> - 👍🏼 The project has a Top 10 Risks List.
|
||||
> - 💣 The Top 10 Risks List is not kept up to date.
|
||||
> - 👍🏼 The project team develops risk-management plans for each risk on the Top 10 Risks List.
|
||||
> - 👍🏼 The project leaders hire well-qualified people (waiting for qualified people, if necessary), rather than just hiring whoever is available first.
|
||||
> - 👍🏼 Time accounting is begun before requirements development begins.
|
||||
> - 👍🏼 All of the above considerations are formalized in a Software Development Plan.
|
||||
> - 💣 The Software Development Plan isn't placed under change control.
|
||||
> - 💣 The Software Development Plan isn't actually followed by the development team.
|
||||
|
||||
### Requirements Development
|
||||
|
||||
> [!question] Survival Check - Requirements Development
|
||||
> - 👍🏼 The project team identifies a set of key end users who can be trusted to shape the software.
|
||||
> - 👍🏼 The developers create several versions of a basic prototype until they find one that the users are excited about.
|
||||
> - 💣 Prototyping stops while users are still only lukewarm about the prototype.
|
||||
> - 👍🏼 The developers extend the User Interface Prototype to elicit detailed requirements from users.
|
||||
> - 💣 The prototype is not kept broad and shallow, and time is wasted providing deep functionality that will be rewritten for the final software.
|
||||
> - 👍🏼 The project team develops a User Manual/Requirements Specification to use as the detailed requirements specification.
|
||||
> - 👍🏼 The fully developed prototype is baselined and placed under change control.
|
||||
> - 💣 The project team attempts to use the prototype code in the real software.
|
||||
> - 👍🏼 A separate, non-user-interface requirements document is created, reviewed, and placed under change control.
|
||||
|
||||
### Quality Assurance
|
||||
QA matters because it makes development easier and cheaper. If mistakes and defects are detected upstream they are 50-200 times cheaper, which is why a good quality assurance system pays out.
|
||||
Quality is important because the software usually acts as a foundation for business decisions, more software and usually lives longer than you might expect.
|
||||
|
||||
> [!Quote] Quick and Dirty
|
||||
> The problem with quick and dirty, as some people have said, is that dirty remains long after quick has been forgotten.
|
||||
|
||||
#### Quality Assurance Plan
|
||||
This document writes down commitments to quality assurance onto paper:
|
||||
- Software quality assurance activities must be planned
|
||||
- The plan for quality assurance must be committed to writing
|
||||
- Quality assurance must beginn in requirements phase or earlier
|
||||
- Development and quality assurance of the same elements cannot be performed by the same person.
|
||||
- Train team members in how to perform quality assurance activities.
|
||||
- Provide adequate funding for quality assurance activities
|
||||
|
||||
Typical Quality assurance activities are:
|
||||
- **defect tracking**: keep record of each defect found, its source, when it was found, when it was resolved, how it was resolved (fixed or not)
|
||||
- **unit testing**: unit refers to subroutine, module, class or even larger programming entity. This is done by developers, or on the git cloud provider automatically
|
||||
- **source-code tracing**: interactive debugging line by line. done by developer.
|
||||
- **technical reviews**: reviews are performed by peers. check all technical work products. Done by developers, QA-team just ensures that they are being held.
|
||||
- **integration testing**: test new code together with existing code / codebase. Done by developer
|
||||
- **system testing**: Test the entire system for the purpose of finding defects. Performed by independent test organization / test engineer
|
||||
|
||||
##### Defect Tracking
|
||||
- document each individual defect
|
||||
- keep statistics: \# open defects, average time requiered to correct a defect, percentage of defects resolved.
|
||||
- track only defects that have been comitted. Beforehand you should just fix them (put them into your personal todos.)
|
||||
- Put defect reports under change control and make it public: automatically in jira / gitlab issues
|
||||
- create a defect report template
|
||||
|
||||
##### Technical Reviews
|
||||
This is an activity that assures quality upstream in the process.
|
||||
- can be: walkthroughs, inspections, code reading
|
||||
- time to talk about code:
|
||||
- juniors can learn from seniors and seniors can fix problems in juniors code
|
||||
- challenge old ways of doing things
|
||||
|
||||
Review pattern:
|
||||
1. **Notification and distribution**: developer informs reviewer that code is ready for review and shares material for review
|
||||
2. **Preparation**: Review happens, aided by checklist of common errors
|
||||
3. **Review Meeting**: talk about the review
|
||||
4. **Review Report**: log statistics of review: amount of defects, time spent for review, meeting, etc, pass or fail
|
||||
5. **Follow-up**: Fix the problems and review again until product passes the review.
|
||||
|
||||
Suggestions
|
||||
- focus on defect detection, do not try to create solutions
|
||||
- start reviews early in the project
|
||||
- keep technical reviews technical and be honest about defects
|
||||
- keep track of what material has been reviewed
|
||||
- record the defects during reviews and list them in the report
|
||||
- Verify that defects found during review are actually fixed (in the follow-up)
|
||||
- make review results public to the project team
|
||||
- schedule time for reviews and errorfixing of found defects
|
||||
|
||||
##### System Testing
|
||||
This is an activity that assures quality downstream in the process, compared to technical reviews.
|
||||
Usually developers cannot wear both the developers' hat as well as the tester's hat: have different people do this.
|
||||
|
||||
- Start system testing as soon as you have the first executable software
|
||||
- Use a requirements traceability matrix to ensure all requirements are covered.
|
||||
- test cases as rows
|
||||
- requirements as columns
|
||||
- every row and column need at least one mark, else they are useless
|
||||
- Automate the testcases. The more critical the software is, the more testers per developers are needed.
|
||||
|
||||
> [!Quote] Testing vs Quality Assurance
|
||||
> Testing is a means of discovering the quality level of a software system, not a means of assuring software quality.
|
||||
|
||||
##### Beta Testing
|
||||
Release of software to a selected group of testers.
|
||||
|
||||
##### Other
|
||||
![[Pasted image 20250110145533.png]]
|
||||
![[Pasted image 20250110145548.png]]
|
||||
|
||||
Have measurable criteria for software releases.
|
||||
|
||||
> [!question] Survival Check
|
||||
> - 👍🏼 Project has a written, approved Quality Assurance Plan.
|
||||
> - 💣 Project isn't following the written plan.
|
||||
> - 👍🏼 Quality assurance is initiated in parallel with requirements work.
|
||||
> - 👍🏼 Defect tracking software is placed online at requirements development time, and defects are tracked from the beginning of the project.
|
||||
> - 👍🏼 Developers review all designs and code before the designs and code are considered "done."
|
||||
> - 💣 No designs or code have failed their reviews, suggesting that reviews are superficial.
|
||||
> - 💣 Developers don't source trace and unit test their own source code prior to submitting it for review, which gives rise to an unwieldy number of defects that have to be tracked from reviews onward.
|
||||
> - 👍🏼 The Quality Assurance Plan calls for an independent quality assurance group.
|
||||
> - 💣 No funding is available for an independent quality assurance group.
|
||||
> - 👍🏼 The Quality Assurance Plan contains measurable criteria that are used to determine whether the software is ready to be released.
|
||||
|
||||
### Architecture
|
||||
|
||||
### Final Preparations
|
||||
The final preparations should be started when architecture design is nearly finished. It includes:
|
||||
- create project estimates
|
||||
- write a staged delivery plan
|
||||
- perform ongoing planning activities
|
||||
|
||||
#### Project Estimates
|
||||
The goal is to estimate effort, cost and schedule. This should be done by the most experienced person doing similar work or an expert estimator.
|
||||
> [!NOTE]- Fibonacci based estimation of effort
|
||||
> [[Martin Albrecht|Martin]] told me about their estimation procedure, where they use fibonacci numbers for estimating efforts of features or user stories. It is difficult to say if something takes 8 or 9 days, but if something takes 1, 2, 3, 5, 8, 13, 21 days is much easier.
|
||||
|
||||
Apart from the obvious activities such as architecture, coding, general planning, user documentation, etc. there are less obvious activities that should be accounted for:
|
||||
- interaction with customers/end users
|
||||
- reviews
|
||||
- fixing problems during reviews
|
||||
- maintaining things like:
|
||||
- revision control systems
|
||||
- daily build scripts
|
||||
- technical training
|
||||
- holidays, vacations and sick days
|
||||
- answering questions from QA and documentation
|
||||
|
||||
Including those less obvious activities is important in order to be more accurate with your time planning. Because if the time plan is really far away from reality, the team stops taking the goal seriously which decreases productivity.
|
||||
Don't plan with the team doing overtime. This can be a reserve if the project falls behind or something similar.
|
||||
Oftentimes with troublesome projects the developers say that the estimates are unrealistic from the start. Lack of buy-in from developers is at best a warning sign that the goals are unachievable. At worst, it indicates an adversarial relationship between developers and management, which comes with many more problems.
|
||||
Redoing the estimation work is crucial. It shows flexibility and will be more accurate the more the team learns about its progress. Further it is important to keep estimates under change control.
|
||||
|
||||
#### Milestone Targets
|
||||
The team should use the estimates from above to put due dates for important milestones such as completing the architecture, completing the stages, and releasing the software.
|
||||
|
||||
#### Staged Delivery Plan
|
||||
The most important functionality is delivered first. The staged delivery approach doesn't reduce the actual development time, but it reduces the development time that is perceived. Every stage that is completed and celebrated makes people feel the success and thus the ultimate goal seems closer. The architecture needs to be build such that staged delivery is possible.
|
||||
Not every stage necessarily needs to be shipped to the customer. Maybe only the 4th stage will be shipped, because the stages before that are too simple. Nonetheless, the simpler stages help in having a good development approach.
|
||||
|
||||
|
||||
> [!question] Survival Check - Final Preparations
|
||||
> - 👍🏼 The project team creates its first estimate after preliminary requirements development is complete.
|
||||
> - 💣 Estimates do not account for normal activities such as holidays, weekends, and vacations.
|
||||
> - 💣 Developers don't believe the estimates are realistic.
|
||||
> - 👍🏼 Estimates are updated after detailed requirements development and again after architectural design.
|
||||
> - 👍🏼 The project has a Staged Delivery Plan that organizes the stages into theme releases.
|
||||
> - 💣 The stages are not defined in detail.
|
||||
> - 👍🏼 The project's risk-management, vision, decision-making, and personnel plans are up-to-date.
|
||||
> - 👍🏼 The project's Software Development Plan is up-to-date and is being followed.
|
||||
|
||||
### Beginning of Stage Planning
|
||||
For each stage a detailed plan is needed. The project team creates an individual stage plans. Each stage includes planning, design, construction, testing and preparation for release. The idea behind the stages is to convert a big risky project into a stage of smaller more manageable projects.
|
||||
|
||||
#### Stage planning overview
|
||||
- requirements updates
|
||||
- detailed design
|
||||
- construction
|
||||
- test case creation
|
||||
- user documentation updates
|
||||
- technical reviews
|
||||
- defect corrections
|
||||
- technical coordination
|
||||
- risk management
|
||||
- project tracking
|
||||
- integration and release
|
||||
- end-of-stage wrap up
|
||||
|
||||
Miniature Milestones are a great way to add visibility to the development process. They should be defined in a way where they can be either *done* or *not done*.
|
||||
When only long-term milestones are used, the developers can easily lose a day here or a week there— people spend time on detours that seem interesting or productive in some vague sense but that fail to move the project forward.
|
||||
|
||||
|
||||
> [!question] Survival Check - Stage Planning
|
||||
> - 👍🏼 Planning is conducted at the beginning of each stage to prepare for that stage's activities.
|
||||
> - 👍🏼 Stage planning includes requirements review, detailed design, coding and code reviews, test case creation, user documentation updates, in-stage defect correction, technical coordination, integration and release, risk management, project tracking, and other important activities.
|
||||
> - 👍🏼 The project team creates a set of miniature milestones to aid in tracking progress throughout the stage.
|
||||
> - 💣 The list of miniature milestones does not include all activities.
|
||||
> - 💣 The project is not actually tracked against the list of miniature milestones.
|
||||
> - 👍🏼 The project manager adopts a hands-on approach to the project.
|
||||
|
||||
### Detailed Design
|
||||
|
||||
|
||||
|
||||
---
|
||||
## Steps towards the Software release
|
||||
1. Define preliminary risks list
|
||||
2. Define requirements
|
||||
3. Create initial project estimate (budget, schedule, staffing, desired feature set).
|
||||
|
||||
|
||||
## Document List
|
||||
- Top 10 Risk List (keeps being updated) including a risk-management plan for each risk
|
||||
- Software Development Plan
|
||||
- Risk management approach
|
||||
- Risk officer and other roles: personnell strategies
|
||||
- Decision making authority
|
||||
- project scope
|
||||
- publicising of plans and progress
|
||||
- time accounting
|
||||
- once finished sign off by project manager, dev team and Q&A team, then place under change control
|
||||
- Quality Assurance Plan
|
||||
- defect report template to be used to report defects (see page 130)
|
||||
- review checklists for different parts
|
||||
- Software architecture plan (less than 100 pages, diagram heavy)
|
||||
- Staged Delivery Plan
|
||||
- Individual stage plans --> add to the software development plan once its finished
|
||||
## Tool list
|
||||
- Anonymous risk-reporting channel
|
||||
- time tracking (helps for future estimating practices)
|
||||
|
||||
## Review List
|
||||
- Review Top 10 Risks every 2 Weeks (see page 97)
|
||||
|
||||
## Checkpoints
|
||||
- reestimate of the schedule and cost
|
||||
- during preliminary requirements development
|
||||
- during detailed requirements development
|
||||
- during architectural design
|
||||
-
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
```query
|
||||
Software Project Survival Guide Steve McConnell
|
||||
-file: "Software Project Survival Guide by Steve McConnell.md"
|
||||
```
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Surrounded by Idiots by Thomas Erikson
|
||||
created_date: 2024-10-25
|
||||
updated_date: 2024-10-25
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
- psychology
|
||||
type: book
|
||||
book_name: Surrounded by Idiots
|
||||
author: Thomas Erikson
|
||||
status: started
|
||||
---
|
||||
# Surrounded by Idiots by Thomas Erikson
|
||||
- **🏷️Tags** : #10-2024 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
> [!warning]
|
||||
> Apparently there is no scientific background to the claims of the book made by Thomas Erikson. It is based on the [[Personality Tests#DiSC|DiSC]] test, which has its origin in the 1930s and has scientifically not been show accurate. The results have high reliability (consistent results over time) but their validity is questionable.
|
||||
|
||||
Nonetheless, I think there are learnings in the books. The way the different personalities are described is accurate and I did remember several interactions with people while reading it. It is important not to judge people's character through the lens of the colours, but rather using it to strategise the best responses with respect to behaviour. If someone shows red behaviour, we take it as red behaviour and act accordingly - we don't say the person is red. Behaviours can be very environment dependent.
|
||||
A critical comment can be found here: [One of Sweden's biggest scientific bluffs – Vetenskap och Folkbildning](https://www.vof.se/blogg/one-of-swedens-biggest-scientific-bluffs/).
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
> [!info] Import Clippings from Kindle
|
||||
> Annotate Clippings with thoughts and cross references
|
||||
|
||||
|
||||
|
||||
---
|
||||
```query
|
||||
Surrounded by Idiots Thomas Erikson
|
||||
-file: "Surrounded by Idiots by Thomas Erikson.md"
|
||||
```
|
||||
@@ -0,0 +1,108 @@
|
||||
---
|
||||
title: The 7 Habits of Highly Effective People by Stephen Covey
|
||||
created_date: 2024-11-28
|
||||
updated_date: 2024-11-28
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
- self-help
|
||||
type: book
|
||||
book_name: The 7 Habits of Highly Effective People
|
||||
author: Stephen Covey
|
||||
status: finished
|
||||
---
|
||||
# The 7 Habits of Highly Effective People by Stephen Covey
|
||||
- **🏷️Tags** : #11-2024 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
> [!info] Import Clippings from Kindle
|
||||
> Annotate Clippings with thoughts and cross references
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
### Paradigms and Principles
|
||||
Paradigms: what are my maps, my lenses, my ways to see, perceive and interpret the world, the relationships? The better I know them the more I can abstract, experiment, listen to others and thereby getting a larger picture and far more objective view.
|
||||
|
||||
|
||||
Most breakthroughs in science are usually a break with traditional methods and traditional ways of thinking. So called Paradigm Shifts.
|
||||
|
||||
Character Ethics vs Personality Ethics: a paradigm shift which is negative: character ethics is based on principles deeply rooted, whereas personality ethics is based on attitude and behavior.
|
||||
|
||||
Story of the man with the kids in the subway whose mother just died. Small adjustment —> you suddenly feel compassion
|
||||
|
||||
In order to *see* differently, sometimes you need to *be* differently.
|
||||
|
||||
Principles: fairness, integrity, honesty, human dignity, service, quality, excellence, potential, growth, patience, nurturance, encouragement.
|
||||
|
||||
Principles are not practices, which are specific actions or activities and thus change with different circumstances. Principles are deeply rooted and materialize in terms of habits. They are not Values - values are the maps, trying to describe the underlying territory, which are the principles.
|
||||
|
||||
### Private Victory
|
||||
#### Be Proactive
|
||||
Conditioning: it would be easy to say that *genetic, psychic (upbringing) and environmental (current environment ) determinism* shapes our behaviors. It‘s the stimulus / response theory which says we‘re conditioned to respond in a certain way to different stimuli.
|
||||
This lets us create a framework:
|
||||
|
||||
> [!NOTE] Between Stimulus and Response, Man has freedom to choose
|
||||
> Victor Frankl, being tortured in the Nazi’s concentration camps realized that the last human freedom is to choose how different stimuli are going to affect you. Ergo you can choose your response.
|
||||
|
||||
Projecting yourself to be where you want to be helps with choosing the right response today for a future goal.
|
||||
Self-awareness, imagination, conscience (deep inner awareness of what is right and wrong), independent will, are traits that help shape this ability to create a gap in between stimulus and response.
|
||||
|
||||
Being proactive means that as a human being, we are responsible for our own life. Our behavior is a function of our decisions, not our conditions.
|
||||
|
||||
Being proactive requires a paradigm shift: you need to abstract the stimulus and find out how it relates to your life and situation. Then you are free to chose the response.
|
||||
|
||||
Act or be acted upon: you choose if you want to act or be acted upon.
|
||||
|
||||
Language is important to distinguish between proactivism and reactivism. It shows how someone responds to circumstances.
|
||||
|
||||
### Circle of Influence vs. Circle of Concern
|
||||
The circle of Concern: defines what you are concerned about.
|
||||
The circle of influence: is what you can actually influence.
|
||||
Proactive people focus on the circle of influence. What can they influence? Because everything else is not worthwhile to pursue.
|
||||
|
||||
Problems can be of different nature:
|
||||
- direct control: private victories - this is in your realm of possibility
|
||||
- Indirect control: public victories - you need to influence other people for putting indirect control
|
||||
- No control: a proactive person acknowledges this and accepts the problem to be able to live with it
|
||||
|
||||
A proactive person approaches every problem with this distinction
|
||||
|
||||
The story about the distinct CEO that was very commanding reminds me of [[Floris]]. I have been very reactive there, as a proactive person I should have understood Florises inner workings and use them to better communicate. What are Florises weaknesses? How can I complement them? If Floris expects something, how can I fulfill that in his view? How can I present work of the team such that he agrees?
|
||||
What is my circle of influence within OneSec? And what is my circle of concern?
|
||||
|
||||
Focus on being instead of having. Focus on problems that lie within your realm instead of problems out there. Focus on your attitude instead of other people’s weaknesses. Focus on your unconditional love and support for your partner and that will hopefully come back to you, in the end it is all that you can do.
|
||||
|
||||
The consequences of our actions often lie in the circle of concern, but not in the circle of influence. Therefore, we cannot control them and need to accept them when they happened. Bad decisions are mistakes, we cannot change what happened in the past, and thus not change what is in the circle of concern, but rather our attitude to it and learn from the mistakes to not make them the next time around. That is what lies within the circle of influence. Ignoring past mistakes and not to correct it and learn from it makes everything worse, because it is self-deceiving often including lies to one-self and others.
|
||||
|
||||
|
||||
---
|
||||
## Todos
|
||||
- [ ] what are paradigm shifts I have experienced?
|
||||
- [ ] What is my contribution to this world? How do I serve?
|
||||
|
||||
|
||||
## My Stories
|
||||
[[Stefan Fritsche|Dad]] hat auch ein paradigm shift gemscht, als er akzeptiert hat das der Lohnunterschied wegen der Einstufung nicht angepasst wird und er aber sich selber von einer anderen Seite gesehen hat mit Bezug auf Familie, Haus und generelles Wohlsein.
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: Utopien für Realisten by Rutger Bregman
|
||||
created_date: 2024-10-27
|
||||
updated_date: 2024-10-27
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
type: book
|
||||
book_name: Utopien für Realisten
|
||||
author: Rutger Bregman
|
||||
status: not_started
|
||||
---
|
||||
|
||||
# Utopien für Realisten by Rutger Bregman
|
||||
- **🏷️Tags** : #10-2024 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
> [!info] Import Clippings from Kindle
|
||||
> Annotate Clippings with thoughts and cross references
|
||||
|
||||
Das problem der Armen ist das sie kein Geld haben, nicht das sie faul oder dumm sind.
|
||||
Das Problem der Obdachlosen ist das sie kein Dach über dem Kopf haben und nicht etwas anderes. Die Lösung für diese Probleme ist den Leuten zu geben was sie brauchen, ohne Bedingungen. Es rechnet sich sogar finanziell, da die Ausgaben die sonst rundherum gebraucht wurden (Polizei, Gericht, Berater, etc) teurer sind als die Leute einfach zu bezahlen.
|
||||
|
||||
Das Hauptproblem der Gesellschaft ist nicht die effektive Armut, sondern die Ungleichheit zwischen den Reichsten und den Ärmsten. Das BIP korreliert nicht mit dem Index gesellschaftlicher Probleme, die Ungleichheit jedoch schon. Auch wenn heute die Ärmsten reicher sind als Könige vor 200 Jahren, so vergleichen sie sich doch mit den Reichsten von heute was einen psychologischen Druck veranlasst. Das führt zu mehr Misstrauen, Statusangst, Mobbing.
|
||||
Es braucht ein bisschen Ungleichheit als Treiber für Arbeitsmotivation und Unternehmertum (wie [[Potential]] in Physik). Zu viel hemmt sogar das Wirtschaftswachstum.
|
||||
|
||||
|
||||
> [!Quote] George Santayana (1863-1952)
|
||||
> Wer sich nicht an die Vergangenheit erinnern kann, ist dazu verurteilt, sie zu wiederholen.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Oscar Wilde erklärte, sobald wir das Land des Überflusses erreicht hätten, müssten wir unseren Blick auf den Horizont richten und erneut die Segel setzen: «Fortschritt ist die Verwirklichung von Utopien.» Aber der Horizont bleibt leer. Das Land des Überflusses ist in Nebel gehüllt. Just in dem Moment, in dem wir uns der historischen Aufgabe hätten stellen sollen, diese rei-che, sichere und gesunde Welt mit Sinn zu erfüllen, beerdigten wir stattdessen die Utopie. Und wir haben keinen neuen Traum, durch den wir sie ersetzen könnten, weil wir uns keine bessere Welt als die vorstellen können, in der wir heute leben. Tatsächlich glauben die meisten Menschen in den reichen Ländern, dass es ihren Kindern schlechter gehen wird als ihnen."
|
||||
|
||||
|
||||
|
||||
George Orwell hatte am eigenen Leib erfahren, was es bedeutete, arm zu sein. In seinen Erinnerungen *Erledigt in Paris und London (Down and Out in Paris and London, 1933, deutsch 1978)* schreibt er: "Man dachte, es wäre alles ganz einfach; es ist aussergewöhnlich kompliziert. Man dachte, es wäre schrecklich; es ist nur schmutzig und langweilig"
|
||||
Orwell beschreibt, wie er manchmal den ganzen Tag im Bett lag, weil es nichts gab, für das es sich gelohnt hätte aufzustehen. Das Problem mit der Armut sei, dass sie "die Zukunft auslöscht". Dem Armen bleibe nichts anderes übrig, als im Hier und Jetzt zu überleben. Und Orwell wundert sich darüber, dass manche Leute "einfach annehmen, sie hätten ein Recht darauf dir zu predigen und vorzubeten, nur weil dein Lohn unter einem bestimmten Schnitt gefallen ist".
|
||||
|
||||
---
|
||||
```query
|
||||
Utopien für Realisten Rutger Bregman
|
||||
-file: "Utopien für Realisten by Rutger Bregman.md"
|
||||
```
|
||||
@@ -0,0 +1,15 @@
|
||||
|
||||
Podcast gehört — möchte mehr mit Alena über solche dinge reden und mir selber bewusst werden was ich will.
|
||||
[https://open.spotify.com/episode/4MRtO86GkDzJys8vDpCf3p?si=T8mQE5ChRjigVTToAYnkVw&context=spotify%3Ashow%3A5vpK1ZJdliZiJlV79cQlI0](https://open.spotify.com/episode/4MRtO86GkDzJys8vDpCf3p?si=T8mQE5ChRjigVTToAYnkVw&context=spotify%3Ashow%3A5vpK1ZJdliZiJlV79cQlI0)
|
||||
|
||||
|
||||
|
||||
Sign up to get unlimited songs and podcasts with occasional ads. No credit card needed.
|
||||
|
||||
![[6a976d1807c1f681d108660cfa0be403d6cc8c82]]
|
||||
|
||||
## Episode Description
|
||||
|
||||
So jung, so attraktiv, so dynamisch hat sie sich seit Jahren nicht mehr gefühlt. Die Affäre mit dem Arbeitskollegen beflügelt – selbst die eigene Beziehung. Was also soll daran falsch sein? Aussenbeziehungen sind eine Bewährungsprobe für die Partnerschaft. Einmal aufgedeckt, stellt sie alles in Frage. Wie soll es weitergehen? We
|
||||
|
||||
[See all episodes](https://open.spotify.com/show/5vpK1ZJdliZiJlV79cQlI0)
|
||||
@@ -0,0 +1,28 @@
|
||||
https://spotify.link/FKF11J9RNDb
|
||||
|
||||
[https://oxman.com](https://oxman.com/)
|
||||
|
||||
|
||||
Spannende Persönlichkeit.
|
||||
|
||||
Ich bin grundsätzlich sehr motiviert vom Gedanken alles im Sinne von Win-Win mit der Natur zu machen.
|
||||
|
||||
Erstaunt hat mich:
|
||||
- Biomasse < als vom Menschen hergestellte Masse (Asphalt, auto, Häuser, etc)
|
||||
- Komplette Synergie zwischen Humanismus und Natur
|
||||
- We design and let nature grow
|
||||
|
||||
|
||||
The future of design is to create highly controlled systems that enable the loss of control. Just like nature: it leads to great diversification.
|
||||
|
||||
|
||||
Creativity is all about letting go. Without it you cannot be creative.
|
||||
|
||||
Elegant definition of faith or fate ( i thinl the latter): ratio of who you are and who you want to be
|
||||
|
||||
|
||||
|
||||
Sometimes you need to let go of a dream to allow for another to really grow
|
||||
|
||||
#research dreams: actual night dreams vs dreaming for the future. Ich selber träume nicht deshalb möchte ich wissen wieso nicht und was ich ändern kann damit ich träumen kann
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
# 21 Lessons for the 21st Century
|
||||
|
||||
|
||||
|
||||
## Metadata
|
||||
- Author: [[Yuval Noah Harari]]
|
||||
- Full Title: 21 Lessons for the 21st Century
|
||||
- Category: #books
|
||||
|
||||
## Highlights
|
||||
- Certain chapters celebrate human wisdom, others highlight the crucial role of human stupidity. (Location 84)
|
||||
@@ -0,0 +1,14 @@
|
||||
# 25 Year Framework
|
||||
|
||||
|
||||
|
||||
## Metadata
|
||||
- Author: [[Year Framework_ Your 21st]]
|
||||
- Full Title: 25 Year Framework
|
||||
- Category: #books
|
||||
|
||||
## Highlights
|
||||
- Becoming the master of your “Moving Future. ” You can begin to get the maximum impact from each one of your 100 quarters by setting up the current 90-day period in terms of simple, short-term, measurable, and achievable goals. (Page 24)
|
||||
- Continually make creative course corrections. As we saw with The Moving Future exercise in the previous chapter, achieving ve “multiplier” goals in each 90-day time frame throughout the 25-year period keeps your morale high, maintains your momentum for getting things done, and gets you excited about your goals for the next quarter and beyond (Page 26)
|
||||
- Once you develop a 25-Year Framework for your future, you have a lter that increasingly weeds out ideas, activities, and enterprises that won’t last 25 years. This ltering mindset grows naturally over each of your 100 quarters as a result of the Moving Future thinking process (Page 38)
|
||||
- Many people feel anxiety about time because their brains are so full. They see everything they want to do as having to be done right now, all at once, and everything is competing with everything else (Page 63)
|
||||
@@ -0,0 +1,17 @@
|
||||
# Das Herzenhören
|
||||
|
||||
|
||||
|
||||
## Metadata
|
||||
- Author: [[Sendker, Jan-Philipp]]
|
||||
- Full Title: Das Herzenhören
|
||||
- Category: #books
|
||||
|
||||
## Highlights
|
||||
- mit meinem Vater zu tun? Nichts. Überhaupt nichts.« Ich (Location 1259)
|
||||
- seiner Kindheit suchte, und dass ich keinen Respekt hätte vor Menschen, die das täten. Ich wiederholte, dass ich mir nicht vorstellen könne, dass mein Vater je in seinem Leben blind gewesen sei, und je länger ich erzählte, desto weniger richteten sich meine Worte an U Ba. Ich sprach zu mir, es war der Versuch, mir einzureden, dass sich die Wahrheit auf die Grenzen meiner Vorstellungskraft beschränken musste. U Ba hörte zu und nickte, und es schien, als wisse (Location 1261)
|
||||
- im Wesentlichen aber versuche er weiterzugeben, was das Leben ihn gelehrt habe: dass der Reichtum eines Menschen die Gedanken seines Herzens sind. (Location 1573)
|
||||
- Das Problem sind nicht die Augen und die Ohren, Tin Win. Wut macht blind und taub. Angst macht blind und taub. Neid und Misstrauen. Die Welt schrumpft, sie gerät aus den Fugen, wenn du wütend bist oder Angst hast. Für uns genauso wie für jeden, der mit seinen Augen sieht. Er merkt es nur nicht.« (Location 1686)
|
||||
- »Jeder Mensch, jede Kreatur hat Angst. Sie umgibt uns, wie die Fliegen den Misthaufen des Ochsen. Tiere schlägt sie in die Flucht, sie reißen aus und rennen oder fliegen oder schwimmen, bis sie sich in Sicherheit wähnen oder vor Erschöpfung tot umfallen. Wir Menschen sind nicht wirklich klüger. Wir ahnen, dass es auf der Welt keinen Ort gibt, wo wir uns vor der Angst verstecken können, und trotzdem versuchen wir es. Wir streben nach Reichtum und Macht. Wir geben uns der Illusion hin, stärker zu sein als die Angst. Wir versuchen zu herrschen. Über unsere Kinder und unsere Frauen, über unsere Nachbarn und Freunde. Herrschsucht und Angst haben etwas gemein: Sie kennen keine Grenzen. Aber mit der Macht und dem Reichtum ist es wie mit dem Opium, das ich in meiner Jugend mehr als einmal probierte. Beide halten ihr Versprechen nicht. Das Opium brachte mir nicht das ewige Glück, es verlangte nur nach mehr. Geld und Macht besiegen die Angst nicht. Es gibt nur eine Kraft, die stärker ist als die Angst. Die Liebe.« (Location 1712)
|
||||
- Wenn es doch einmal geschah, dass sie unverhofft und ohne zu warten zu Freunden auf die nächste Bergkuppe getragen wurde, dauerte es immer eine Weile, bis sie wirklich ankam. Die ersten Minuten saß sie schweigend am neuen Ort. Als würde ihre Seele langsamer durch das Tal reisen. Sie hatte das Gefühl, alles und jeder brauchte seine Zeit, so wie die Erde ihre vierundzwanzig Stunden benötigte, um sich einmal um die eigene Achse zu drehen, oder dreihundertfünfundsechzig Tage, um die Sonne zu umrunden. (Location 2218)
|
||||
- »Weil wir nur sehen, was uns bekannt ist. Wir trauen dem anderen immer nur zu, wozu wir selbst in der Lage sind, im Guten wie im Bösen. Deshalb erkennen wir als Liebe vor allem, was unserem Bild von ihr entspricht. Wir wollen geliebt werden, so wie wir selbst lieben. Jede andere Art ist uns unheimlich. Wir begegnen ihr mit Zweifel und Misstrauen, wir missdeuten ihre Zeichen, wir verstehen ihre Sprache nicht. Wir klagen an. Wir behaupten, der andere liebt uns nicht. Dabei liebt er uns vielleicht nur in einer, seiner Weise, die uns nicht vertraut ist. Sie werden, so hoffe ich, verstehen, was ich meine, wenn ich meine Geschichte zu Ende erzählt habe.« (Location 3132)
|
||||
@@ -0,0 +1,34 @@
|
||||
# Shantaram
|
||||
|
||||
|
||||
|
||||
## Metadata
|
||||
- Author: [[Roberts, Gregory David]]
|
||||
- Full Title: Shantaram
|
||||
- Category: #books
|
||||
|
||||
## Highlights
|
||||
- I sometimes think that the size of our happiness is inversely proportional to the size of our house.’ (Location 5308)
|
||||
- percussive and exciting music of towering ambition: the nervous irritation of generators, the merciless metal-to-metal zing of hammers, and the whining insistence of drills and grinders. Snaking lines of sari-clad women carrying dishes of gravel on their heads wove through all the workplaces, from man-made dunes of small stones to the yawning mouths of ceaselessly revolving cement-mixing machines. To my western eyes, those fluid, feminine figures in (Location 5455)
|
||||
- and depend upon the inequalities between us. It was vassal-love, (Location 7007)
|
||||
- That look, that frowning smile, combined shame and exultation because both are essential—shame gives exultation its purpose, and exultation gives shame its reward. We’d saved him as much by joining in his exultation as we had by witnessing his shame. And all of it depended upon our action, our interference in his life, because no man is saved without love. (Location 7952)
|
||||
- It’s forgiveness that makes us what we are. Without forgiveness, our species would’ve annihilated itself in endless retributions. Without forgiveness, there would be no history. Without that hope, there would be no art, for every work of art is in some way an act of forgiveness. Without that dream, there would be no love, for every act of love is in some way a promise to forgive. We live on because we can love, and we love because we can forgive. (Location 7957)
|
||||
- They were poor, tired, worried men, but they were Indian, and any Indian man will tell you that although love might not have been invented in India, it was certainly perfected there. (Location 8455)
|
||||
- Silence is the tortured man’s revenge. (Location 8648)
|
||||
- ‘But it’s not true. It’s the other way round. Money isn’t the root of all evil. Evil is the root of all money. There’s no such thing as clean money. All the money in the world is dirty, in some way, because there’s no clean way to make it. If you get paid in money, somebody, somewhere, is suffering for it. That’s one of the reasons, I think, why just about everybody—even people who’d never break the law in any other way—is happy to add an extra buck or two to their money on the black market.’ (Location 9506)
|
||||
- But I am sure that the science is right, within the limit of what we know. (Location 10263)
|
||||
- smiling at me as Nazeer drove away, but it was Nazeer’s scowl, (Location 10467)
|
||||
- It was as if I was the one who was keeping secrets; and no matter how thick my mind became with thoughts of the murder, I never admitted them to him. (Location 11741)
|
||||
- ‘In order to know about any act or intention or consequence, we must first ask two questions. One, what would happen if everyone did this thing? Two, would this help or hinder the movement toward complexity?’ (Location 11791)
|
||||
- his young face assumed a numb expression. I knew that expression. I sometimes caught it, by chance, in the mirror: the way we look when the part of happiness that’s trusting and innocent is ripped away, and we blame ourselves, rightly or wrongly, for its loss. (Location 12227)
|
||||
- It was black money, and black money runs through the fingers faster than legal, hard-earned money. If we can’t respect the way we earn it, money has no value. If we can’t use it to make life better for our families and loved ones, money has no purpose. (Location 13000)
|
||||
- famous for its delicious faloodah drinks, but they were insipid (Location 14168)
|
||||
- ‘Remember,’ Khader said insistently, resting his hand on my forearm to emphasise his words. ‘Sometimes it is necessary to do the wrong thing for the right reasons. The important thing is to be sure that our reasons are right, and that we admit the wrong—that we do not lie to ourselves, and convince ourselves that what we do is right.’ (Location 15114)
|
||||
- Love is the passionate search for a truth other than your own; and once you feel it, honestly and completely, love is forever. Every act of love, every moment of the heart reaching out, is a part of the universal good: it’s a part of God, or what we call God, and it can never die. (Location 15762)
|
||||
- I didn’t know then, as I do now, that love’s a one-way street. Love, like respect, isn’t something you get; it’s something you give. (Location 16137)
|
||||
- He’d been able to deal with that pain because he’d accepted his own part in causing it. I’d never accepted my share of responsibility—right up to that moment—for the way my marriage had failed or for the heartache that had followed it. That was why I’d never dealt with it. (Location 18495)
|
||||
- Nothing in any life, no matter how well or poorly lived, is wiser than failure or clearer than sorrow. And in the tiny, precious wisdom that they give to us, even those dread and hated enemies, suffering and failure, have their reason and their right to be. (Location 18508)
|
||||
- I never told her that—what her affectionate and unconditional acceptance meant to me. So much, too much, of the good that I felt in those years of exile was locked in the prison cell of my heart: those tall walls of fear; that small, barred window of hope; that hard bed of shame. I do speak out now. I know now that when the loving, honest moment comes it should be seized, and spoken, because it may never come again. And unvoiced, unmoving, unlived in the things we declare from heart to heart, those true and real feelings wither and crumble in the remembering hand that tries too late to reach for them. (Location 18683)
|
||||
- They couldn’t understand that every time I entered the slum I felt the urge to let go and surrender to a simpler, poorer life that was yet richer in respect, and love, and a vicinal connectedness to the surrounding sea of human hearts. They couldn’t understand what I meant when I talked about the purity of the slum: they’d been there, and seen the wretchedness and filth for themselves. They saw no purity. But they hadn’t lived in those miraculous acres, and they hadn’t learned that to survive in such a writhe of hope and sorrow the people had to be scrupulously and heartbreakingly honest. That was the source of their purity: above all things, they were true to themselves. (Location 18883)
|
||||
- pathway take the sheaves of rupee notes we’d brought as alms. (Location 19393)
|
||||
- Looking at the people, listening to the breathing, heaving, laughing, struggling music of the slum, all around me, I remembered one of Khaderbhai’s favourite phrases. Every human heartbeat, he’d said many times, is a universe of possibilities. And it seemed to me that I finally understood exactly what he’d meant. He’d been trying to tell me that every human will has the power to transform its fate. I’d always thought that fate was something unchangeable: fixed for every one of us at birth, and as constant as the circuit of the stars. But I suddenly realised that life is stranger and more beautiful than that. The truth is that, no matter what kind of game you find yourself in, no matter how good or bad the luck, you can change your life completely with a single thought or a single act of love. (Location 19841)
|
||||
@@ -0,0 +1,25 @@
|
||||
# Surrounded by Idiots
|
||||
|
||||
|
||||
|
||||
## Metadata
|
||||
- Author: [[Thomas Erikson]]
|
||||
- Full Title: Surrounded by Idiots
|
||||
- Category: #books
|
||||
|
||||
## Highlights
|
||||
- Everything you say to a person is filtered through his frames of reference, biases, and preconceived ideas (Location 156)
|
||||
- No matter what method you choose to communicate with, as an individual, you will always be in the minority. No matter what kind of behavior you have, the majority of people around you will function differently from you. You can’t just base your method of communication on your own preferences. Flexibility and the ability to interpret other people’s needs is what characterizes a good communicator. (Location 167)
|
||||
- your own behavior? To always be able to act and behave precisely as you feel at the time? You can do that. You can behave exactly as you wish. All you have to do is find the right situation in which to do so. There are two situations in which you can just be you: The first situation is when you’re alone in a room. (Location 193)
|
||||
- The next layer is my attitudes, which are not exactly the same thing as core values. Attitudes are things I have formed opinions about based on my own experiences or on conclusions I have drawn from encounters in the latter part of my schooling, high school, college, or my first job. (Location 259)
|
||||
- But people are different. Some don’t care. They are always themselves because they’ve never reflected upon how they are perceived. The stronger your self-understanding is, the greater your probability of adapting to the people around you. (Location 274)
|
||||
- Reds have no problem being blunt. When asked a specific question, they often say exactly what they think, without any frills. They (Location 349)
|
||||
- They have opinions on most things, and they trot their thoughts out quickly and efficiently. (Location 351)
|
||||
- Just like Reds, Yellows have lots of energy. They find most things interesting, and Yellow individuals are the most curious people you’ll ever meet. Everything new is enjoyable, and a great deal of Yellow energy is spent finding new ways of doing things (Location 527)
|
||||
- For every Green, the group will always come first. Team before self. Remember that. This is a fundamental truth for a Green, and it shouldn’t be challenged too strongly. (Location 718)
|
||||
- Very often a Yellow is both entertaining and inspiring, and as I said, they can inspire people to new ideas. But should you get into a conversation with a Yellow, you need to be observant so that when he catches his breath you can quickly insert a comment. Or simply close the meeting. (Location 1211)
|
||||
- Of course, there’s a remedy—take a course in entertaining rhetoric; then you may be able to keep your Yellow friend’s, partner’s, or colleague’s attention. If you can present your message in a more amusing way, he’ll at least remain seated a bit longer. Rhetoric isn’t the art of talking but rather the art of getting others to listen. (Location 1285)
|
||||
- Think about it: It may have taken you your whole life to come to a particular opinion about the dangerous cholesterol in food, about space travel, or about Britney Spears. Suddenly this guy comes along and says that you should exchange your current opinion for his. It’s not going to happen. The Green is waiting for the right feeling to come over him before he makes any changes. If it doesn’t, well … they’re often rather patient. (Location 1309)
|
||||
- Note: Is that why politics in democratic fashion is so slow?
|
||||
- On one occasion, I heard a Red-Yellow boss describe his employees as uninspired and uninterested in their work. It tormented him because no matter how hard he tried to entice and insist, they never left the starting block. He presented numerous ideas—some of which were very interesting—but nothing happened. It can be like that with Greens. They recognize a good idea as quickly as anyone else. But, for example, while their Red colleagues sprint off with the baton, a Green just sits and waits. Often they’re waiting for the right feeling to convince them of an idea’s merit and if that doesn’t happen, well … they wouldn’t do anything anyway, so they get what they want. Why not just wait and see if the urge to act goes away? (Location 1338)
|
||||
- Note: I see myself in this . But only sometimes mostly with floris
|
||||
@@ -0,0 +1,90 @@
|
||||
# The 7 Habits of Highly Effective People
|
||||
|
||||
|
||||
|
||||
## Metadata
|
||||
- Author: [[Stephen R. Covey;Sean Covey]]
|
||||
- Full Title: The 7 Habits of Highly Effective People
|
||||
- Category: #books
|
||||
|
||||
## Highlights
|
||||
- principles, not on mere techniques or momentary fads; (Location 151)
|
||||
- To focus on technique is like cramming your way through school. You sometimes get by, perhaps even get good grades, but if you don’t pay the price day in and day out, you never achieve true mastery of the subjects you study or develop an educated mind. Did you ever consider how ridiculous it would be to try to cram on a farm—to forget to plant in the spring, play all summer, and then cram in the fall to bring in the harvest? The farm is a natural system. The price must be paid and the process followed. You always reap what you sow; there is no shortcut. (Location 477)
|
||||
- I frequently use this perception demonstration in working with people and organizations because it yields so many deep insights into both personal and interpersonal effectiveness. It shows, first of all, how powerfully conditioning affects our perceptions, our paradigms. If ten seconds can have that kind of impact on the way we see things, what about the conditioning of a lifetime? The influences in our lives—family, school, church, work environment, friends, associates, and current social paradigms such as the Personality Ethic—all have made their silent unconscious impact on us and help shape our frame of reference, our paradigms, our maps. (Location 569)
|
||||
- The more aware we are of our basic paradigms, maps, or assumptions, and the extent to which we have been influenced by our experience, the more we can take responsibility for those paradigms, examine them, test them against reality, listen to others, and be open to their perceptions, thereby getting a larger picture and a far more objective view. (Location 590)
|
||||
- But whether they shift us in positive or negative directions, whether they are instantaneous or developmental, paradigm shifts move us from one way of seeing the world to another. And those shifts create powerful change. Our paradigms, correct or incorrect, are the sources of our attitudes and behaviors, and ultimately our relationships with others. (Location 613)
|
||||
- Principles are not values. A gang of thieves can share values, but they are in violation of the fundamental principles we’re talking about. Principles are the territory. Values are maps. When we value correct principles, we have truth—a knowledge of things as they are. (Location 710)
|
||||
- In all of life, there are sequential stages of growth and development. A child learns to turn over, to sit up, to crawl, and then to walk and run. Each step is important and each one takes time. No step can be skipped. (Location 732)
|
||||
- If you don’t let a teacher know at what level you are—by asking a question, or revealing your ignorance—you will not learn or grow. You cannot pretend for long, for you will eventually be found out. (Location 747)
|
||||
- Thoreau taught, “How can we remember our ignorance, which our growth requires, when we are using our knowledge all the time?” (Location 749)
|
||||
- To relate effectively with a wife, a husband, children, friends, or working associates, we must learn to listen. And this requires emotional strength. Listening involves patience, openness, and the desire to understand—highly developed qualities of character. (Location 755)
|
||||
- My experience has been that there are times to teach and times not to teach. When relationships are strained and the air charged with emotion, an attempt to teach is often perceived as a form of judgment and rejection. But to take the child alone, quietly, when the relationship is good and to discuss the teaching or the value seems to have much greater impact. (Location 799)
|
||||
- But is it possible that my spouse isn’t the real problem? Could I be empowering my spouse’s weaknesses and making my life a function of the way I’m treated? (Location 840)
|
||||
- Habits, too, have tremendous gravity pull—more than most people realize or would admit. Breaking deeply imbedded habitual tendencies such as procrastination, impatience, criticalness, or selfishness that violate basic principles of human effectiveness involves more than a little willpower and a few minor changes in our lives. “Liftoff” takes a tremendous effort, but once we break out of the gravity pull, our freedom takes on a whole new dimension. (Location 910)
|
||||
- Happiness can be defined, in part at least, as the fruit of the desire and ability to sacrifice what we want now for what we want eventually. (Location 933)
|
||||
- If you adopt a pattern of life that focuses on golden eggs and neglects the goose, you will soon be without the asset that produces golden eggs. On the other hand, if you only take care of the goose with no aim toward the golden eggs, you soon won’t have the wherewithal to feed yourself or the goose. Effectiveness lies in the balance—what I call the P/PC Balance. P stands for production of desired results, the golden eggs. PC stands for production capability, the ability or asset that produces the golden eggs. (Location 1029)
|
||||
- “That which we obtain too easily, we esteem too lightly. It is dearness only which gives everything its value. Heaven knows how to put a proper price on its goods.” (Location 1177)
|
||||
- In the midst of the most degrading circumstances imaginable, Frankl used the human endowment of self-awareness to discover a fundamental principle about the nature of man: Between stimulus and response, man has the freedom to choose. (Location 1371)
|
||||
- It means that as human beings, we are responsible for our own lives. Our behavior is a function of our decisions, not our conditions. (Location 1392)
|
||||
- Of course, things can hurt us physically or economically and can cause sorrow. But our character, our basic identity, does not have to be hurt at all. In fact, our most difficult experiences become the crucibles that forge our character and develop the internal powers, the freedom to handle difficult circumstances in the future and to inspire others to do so as well. (Location 1430)
|
||||
- Viktor Frankl suggests that there are three central values in life—the experiential, or that which happens to us; the creative, or that which we bring into existence; and the attitudinal, or our response in difficult circumstances such as terminal illness. (Location 1453)
|
||||
- Many people wait for something to happen or someone to take care of them. But people who end up with the good jobs are the proactive ones who are solutions to problems, not problems themselves, who seize the initiative to do whatever is necessary, consistent with correct principles, to get the job done. (Location 1471)
|
||||
- The language of reactive people absolves them of responsibility. “That’s me. That’s just the way I am.” I am determined. There’s nothing I can do about it. “He makes me so mad!” I’m not responsible. My emotional life is governed by something outside my control. “I can’t do that. I just don’t have the time.” Something outside me—limited time—is controlling me. “If only my wife were more patient.” Someone else’s behavior is limiting my effectiveness. “I have to do it.” Circumstances or other people are forcing me to do what I do. I’m not free to choose my own actions. REACTIVE LANGUAGE PROACTIVE LANGUAGE There’s nothing I can do. Let’s look at our alternatives. That’s just the way I am. I can choose a different approach. He makes me so mad. I control my own feelings. They won’t allow that. I can create an effective presentation. I have to do that. I will choose an appropriate response. I can’t. I choose. I must. I prefer. If only. I will. (Location 1516)
|
||||
- That language comes from a basic paradigm of determinism. And the whole spirit of it is the transfer of responsibility. I am not responsible, not able to choose my response. (Location 1535)
|
||||
- Whether we are aware of it or not, whether we are in control of it or not, there is a first creation to every part of our lives. We are either the second creation of our own proactive design, or we are the second creation of other people’s agendas, of circumstances, or of past habits. (Location 1979)
|
||||
- by our own experience. Admittedly, we’re not omniscient. (Location 2407)
|
||||
- There are a number of techniques using your imagination that can put you in touch with your values. But the net effect of every one I have ever used is the same. When people seriously undertake to identify what really matters most to them in their lives, what they really want to be and to do, they become very reverent. They start to think in larger terms than today and tomorrow. Visualization (Location 2581)
|
||||
- We discovered that the nature of the visualization is very important. If you visualize the wrong thing, you’ll produce the wrong thing. (Location 2612)
|
||||
- One of the main things his research showed was that almost all of the world-class athletes and other peak performers are visualizers. They see it; they feel it; they experience it before they actually do it. They begin with the end in mind. (Location 2617)
|
||||
- After you identify your various roles, then you can think about the long-term goals you want to accomplish in each of those roles. (Location 2671)
|
||||
- As I told the manager of the first hotel I visited, I know a lot of companies with impressive mission statements. But there is a real difference, all the difference in the world, in the effectiveness of a mission statement created by everyone involved in the organization and one written by a few top executives behind a mahogany wall. (Location 2778)
|
||||
- What one thing could you do (something you aren’t doing now) that, if you did it on a regular basis, would make a tremendous positive difference in your personal life? (Location 2972)
|
||||
- Note: Be more proactive in the sense of organizing more high quality evenings. High quality weekend activities such as sporty weekeeneds for example climbing Hiking and others . Alsso be mkore proactive in conversations. Be mkore myself and keep my opinion
|
||||
- What one thing in your business or professional life would bring similar results? (Location 2973)
|
||||
- Note: Be more organized. Have a good plan and stick to it with appropriate and necessary adaptions. Learn to defendd the plan against floris.
|
||||
Hire experts that do what I do slowly in much shorter time.
|
||||
get over my psychological barrier to OneSec.
|
||||
Learner spirit. Take the proper time to fully engulf a topic that needs to bee learned. Put it on an organized learning list and repeat once a while. But don't forget it anymore. Often I cannot defend against flokris because the facts are missing
|
||||
- In addition to self-awareness, imagination, and conscience, it is the fourth human endowment—independent will—that really makes effective self-management possible. It is the ability to make decisions and choices and to act in accordance with them. It is the ability to act rather than to be acted upon, to proactively carry out the program we have developed through the other three endowments. (Location 2999)
|
||||
- Rather than focusing on things and time, fourth-generation expectations focus on preserving and enhancing relationships and on accomplishing results—in short, on maintaining the P/PC Balance. (Location 3048)
|
||||
- (Location 3062)
|
||||
- if you were to fault yourself in one of three areas, which would it be: 1) the inability to prioritize; 2) the inability or desire to organize around those priorities; or 3) the lack of discipline to execute around them, to stay with your priorities and organization? Most people say their main fault is a lack of discipline. On deeper thought, I believe that is not the case. The basic problem is that their priorities have not become deeply planted in their hearts and minds. They haven’t really internalized Habit 2. (Location 3150)
|
||||
- In the words of the architectural maxim, form follows function. Likewise, management follows leadership. The way you spend your time is a result of the way you see your time and the way you really see your priorities. If your priorities grow out of a principle center and a personal mission, if they are deeply planted in your heart and in your mind, you will see Quadrant II as a natural, exciting place to invest your time. (Location 3163)
|
||||
- It’s almost impossible to say “no” to the popularity of Quadrant III or to the pleasure of escape to Quadrant IV if you don’t have a bigger “yes” burning inside. Only when you have the self-awareness to examine your program—and the imagination and conscience to create a new, unique, principle-centered program to which you can say “yes”—only then will you have sufficient independent willpower to say “no,” with a genuine smile, to the unimportant. (Location 3166)
|
||||
- Many people seem to think that success in one area can compensate for failure in other areas of life. But can it really? Perhaps it can for a limited time in some areas. But can success in your profession compensate for a broken marriage, ruined health, or weakness in personal character? True effectiveness requires balance, and your tool needs to help you create and maintain it. (Location 3214)
|
||||
- Note: Absolutely This resonantes to 100p with me
|
||||
- DESIRED RESULTS. Create a clear, mutual understanding of what needs to be accomplished, focusing on what, not how; results, not methods. Spend time. Be patient. Visualize the desired result. Have the person see it, describe it, make out a quality statement of what the results will look like, and by when they will be accomplished. (Location 3407)
|
||||
- Note: Effective delegation
|
||||
- If you know the failure paths of the job, identify them. Be honest and open—tell a person where the quicksand is and where the wild animals are. You don’t want to have to reinvent the wheel every day. Let people learn from your mistakes or the mistakes of others. Point out the potential failure paths, what not to do, but don’t tell them what to do. Keep the responsibility for results with them—to do whatever is necessary within the guidelines. (Location 3415)
|
||||
- It doesn’t help that busyness has become a status symbol, according to research by professors Silvia Bellezza, Neeru Paharia, and Anat Keinan. Throughout history, status has been measured by how much leisure time you have.I Not anymore. As author Brigid Schulte writes, “Unlike a century ago, when Americans showed their status in leisure time, busyness has become the new badge of honor. So even as we bemoan workplaces where everyone is busy and no one is productive, busyness has actually become the way to signal dedication to the job and leadership potential. One reason for this is that, while productivity is relatively easy to measure on a factory floor, or on the farm, we have yet to develop good metrics for measuring the productivity of knowledge workers. So we largely rely on hours worked and face time in the office as markers for effort, and with the advent of technology and the ability to work remotely, being connected and responsive at all hours is the new face time.”II (Location 3583)
|
||||
- The key to saying No is to have a deeper Yes burning inside of you. Clarify the few things you do well, and then start saying No to everything else. Remember, the enemy of the best is the good. In the words of Emerson, “The crime which bankrupts men and nations is turning aside from one’s main purpose to serve a job here or there.” (Location 3620)
|
||||
- We can often live for years with the chronic pain of our lack of vision, leadership, or management in our personal lives. We feel vaguely uneasy and uncomfortable and occasionally take steps to ease the pain, at least for a time. Because the pain is chronic, we get used to it, we learn to live with it. But when we have problems in our interactions with other people, we’re very aware of acute pain—it’s often intense, and we want it to go away. (Location 3731)
|
||||
- Note: Do I have that with OneSec?
|
||||
- Our tendency is to project out of our own autobiographies what we think other people want or need. We project our intentions on the behavior of others. We interpret what constitutes a deposit based on our own needs and desires, either now or when we were at a similar age or stage in life. If they don’t interpret our effort as a deposit, our tendency is to take it as a rejection of our well-intentioned effort and to give up. (Location 3811)
|
||||
- Suppose you and I were talking alone, and we were criticizing our supervisor in a way that we would not dare to do if he were present. Now, what will happen when you and I have a falling-out? You know I’m going to be discussing your weaknesses with someone else. That’s what you and I did behind our supervisor’s back. You know my nature. I’ll sweet-talk you to your face and bad-mouth you behind your back. You’ve seen me do it. That’s the essence of duplicity. Does that build a reserve of trust in my account with you? (Location 3888)
|
||||
- Integrity in an interdependent reality is simply this: you treat everyone by the same set of principles. As you do, people will come to trust you. They may not at first appreciate the honest confrontational experiences such integrity might generate. Confrontation takes considerable courage, and many people would prefer to take the course of least resistance, belittling and criticizing, betraying confidences, or participating in gossip about others behind their backs. But in the long run, people will trust and respect you if you are honest and open and kind with them. (Location 3900)
|
||||
- Dag Hammarskjöld, past secretary-general of the United Nations, once made a profound, far-reaching statement: “It is more noble to give yourself completely to one individual than to labor diligently for the salvation of the masses.” (Location 3979)
|
||||
- P PROBLEMS ARE PC OPPORTUNITIES This experience also taught me another powerful paradigm of interdependence. It deals with the way in which we see problems. I had lived for months trying to avoid the problem, seeing it as a source of irritation, a stumbling block, and wishing it would somehow go away. But, as it turned out, the very problem created the opportunity to build a deep relationship that empowered us to work together as a strong, complementary team. I suggest that in an interdependent situation, every P problem is a PC opportunity—a chance to build the Emotional Bank Accounts that significantly affect interdependent production. (Location 4008)
|
||||
- When a child comes to them with a problem, instead of thinking, “Oh, no! Not another problem!” their paradigm is, “Here is a great opportunity for me to really help my child and to invest in our relationship.” Many interactions change from transactional to transformational, and strong bonds of love and trust are created as children sense the value parents give to their problems and to them as individuals. (Location 4017)
|
||||
- The academic world reinforces Win/Lose scripting. The “normal distribution curve” basically says that you got an “A” because someone else got a “C.” It interprets an individual’s value by comparing him or her to everyone else. No recognition is given to intrinsic value; everyone is extrinsically defined. (Location 4100)
|
||||
- Note: What is intrinsic value? How is it defined?
|
||||
- “Who’s winning in your marriage?” is a ridiculous question. If both people aren’t winning, both are losing. (Location 4118)
|
||||
- My short-term Win will really be a long-term Lose if I don’t get your repeat business. So an interdependent Win/Lose is really Lose/Lose in the long run. (Location 4169)
|
||||
- Experience shows that it is often better in setting up a family business or a business between friends to acknowledge the possibility of No Deal downstream and to establish some kind of buy/sell agreement so that the business can prosper without permanently damaging the relationship. (Location 4241)
|
||||
- He taught the finest, simplest, most practical, yet profound, definition of emotional maturity I’ve ever come across—“the ability to express one’s own feelings and convictions balanced with consideration for the thoughts and feelings of others.” (Location 4270)
|
||||
- Many people think in dichotomies, in either/or terms. They think if you’re nice, you’re not tough. But Win/Win is nice… and tough. It’s twice as tough as Win/Lose. To go for Win/Win, you not only have to be nice, you have to be courageous. You not only have to be empathic, you have to be confident. You not only have to be considerate and sensitive, you have to be brave. To do that, to achieve that balance between courage and consideration, is the essence of real maturity and is fundamental to Win/Win. (Location 4284)
|
||||
- When you’re dealing with a person who is coming from a paradigm of Win/Lose, the relationship is still the key. The place to focus is on your Circle of Influence. You make deposits into the Emotional Bank Account through genuine courtesy, respect, and appreciation for that person and for the other point of view. You stay longer in the communication process. You listen more, you listen in greater depth. You express yourself with greater courage. You aren’t reactive. You go deeper inside yourself for strength of character to be proactive. You keep hammering it out until the other person begins to realize that you genuinely want the resolution to be a real win for both of you. That very process is a tremendous deposit in the Emotional Bank Account. (Location 4343)
|
||||
- There are basically four kinds of consequences (rewards and penalties) that management or parents can control—financial, psychic, opportunity, and responsibility. Financial consequences include such things as income, stock options, allowances, or penalties. Psychic or psychological consequences include recognition, approval, respect, credibility, or the loss of them. Unless people are in a survival mode, psychic compensation is often more motivating than financial compensation. Opportunity includes training, development, perks, and other benefits. Responsibility has to do with scope and authority, either of which can be enlarged or diminished. Win/Win agreements specify consequences in one or more of those areas and the people involved know it up front. So you don’t play games. Everything is clear from the beginning. (Location 4458)
|
||||
- First, see the problem from the other point of view. Really seek to understand and to give expression to the needs and concerns of the other party as well as or better than they can themselves. Second, identify the key issues and concerns (not positions) involved. Third, determine what results would constitute a fully acceptable solution. And fourth, identify possible new options to achieve those results. (Location 4560)
|
||||
- “Pride gets no pleasure out of having something, only out of having more of it than the next man.… It is the comparison that makes you proud: the pleasure of being above the rest.” (Location 4649)
|
||||
- Frustration is the feeling; school is the content. You’re using both sides of your brain to understand both sides of his communication. (Location 4953)
|
||||
- The essence of synergy is to value differences—to respect them, to build on strengths, to compensate for weaknesses. (Location 5319)
|
||||
- And unless people have a high tolerance for ambiguity and get their security from integrity to principles and inner values, they find it unnerving and unpleasant to be involved in highly creative enterprises. Their need for structure, certainty, and predictability is too high. SYNERGY (Location 5344)
|
||||
- Insecure people think that all reality should be amenable to their paradigms. They have a high need to clone others, to mold them over into their own thinking. They don’t realize that the very strength of the relationship is in having another point of view. Sameness is not oneness; uniformity is not unity. Unity, or oneness, is complementariness, not sameness. Sameness is uncreative… and boring. The essence of synergy is to value the differences. (Location 5516)
|
||||
- You may really want to change that level. You may want to create a climate that is more positive, more respectful, more open and trusting. Your logical reasons for doing that are the driving forces that act to raise the level. But increasing those driving forces is not enough. Your efforts are opposed by restraining forces—by the competitive spirit between children in the family, by the different scripting of home life you and your spouse have brought to the relationship, by habits that have developed in the family, by work or other demands on your time and energies. Increasing the driving forces may bring results—for a while. But as long as the restraining forces are there, it becomes increasingly harder. It’s like pushing against a spring: the harder you push, the harder it is to push until the force of the spring suddenly thrusts the level back down. (Location 5611)
|
||||
- You can sidestep negative energy; you can look for the good in others and utilize that good, as different as it may be, to improve your point of view and to enlarge your perspective. (Location 5685)
|
||||
- You can value the difference in other people. When someone disagrees with you, you can say, “Good! You see it differently.” You don’t have to agree with them; you can simply affirm them. And you can seek to understand. (Location 5687)
|
||||
- There’s no other way you could spend an hour that would begin to compare with the Daily Private Victory in terms of value and results. It will affect every decision, every relationship. It will greatly improve the quality, the effectiveness, of every other hour of the day, including the depth and restfulness of your sleep. It will build the long-term physical, spiritual, and mental strength to enable you to handle difficult challenges in life. In the words of Phillips Brooks: Some day, in the years to come, you will be wrestling with the great temptation, or trembling under the great sorrow of your life. But the real struggle is here, now… Now it is being decided whether, in the day of your supreme sorrow or temptation, you shall miserably fail or gloriously conquer. Character cannot be made except by a steady, long continued process. (Location 6011)
|
||||
- The Daily Private Victory—a minimum of one hour a day in renewal of the physical, spiritual, and mental dimensions—is the key to the development of the 7 Habits and it’s completely within your Circle of Influence. It is the Quadrant II focus time necessary to integrate these habits into your life, to become principle-centered. (Location 6153)
|
||||
- So much of our happiness depends on the quality of our relationships. You may think you don’t have time to exercise, go to lunch with a friend, read a book, write in your journal, attend that conference, take a break, or go on a family vacation. In reality, you don’t have time not to. (Location 6286)
|
||||
- My contemplation of life and human nature in that secluded place had taught me that he who cannot change the very fabric of his thought will never be able to change reality, and will never, therefore, make any progress. (Location 6452)
|
||||
@@ -0,0 +1,11 @@
|
||||
# The Fork, the Witch, and the Worm
|
||||
|
||||
|
||||
|
||||
## Metadata
|
||||
- Author: [[Paolini, Christopher]]
|
||||
- Full Title: The Fork, the Witch, and the Worm
|
||||
- Category: #books
|
||||
|
||||
## Highlights
|
||||
- weirding that broke the laws of nature, and second any weirding (Location 1622)
|
||||
@@ -0,0 +1,20 @@
|
||||
# The Name of the Wind
|
||||
|
||||
|
||||
|
||||
## Metadata
|
||||
- Author: [[Patrick Rothfuss]]
|
||||
- Full Title: The Name of the Wind
|
||||
- Category: #books
|
||||
|
||||
## Highlights
|
||||
- snapped. “I’m a tinker and a peddler, and I’m more than both. I’m an arcanist, you great dithering heap of idiot.” “My point exactly,” the mayor said doggedly. “We’re God-fearing people in these parts. We don’t want any meddling with dark things better left alone. We don’t want the trouble your kind can bring.” “My kind?” the old man said. “What do you know about my kind? There probably (Location 1233)
|
||||
- stronger. It felt the same way your body feels after a day of splitting wood, or swimming, or sex. You feel exhausted, languorous, and almost Godlike. This feeling was similar, except it was my intellect that was weary and expanded, languid and latently powerful. I could feel my mind starting to awaken. (Location 1403)
|
||||
- “It doesn’t matter. Try again.” He shook the stone. “Alar is the cornerstone of sympathy. If you are going to impose your will on the world, you must have control over what you believe.” (Location 1437)
|
||||
- looking in his direction. I smiled at Fela. “Perhaps a bestiary,” (Location 5295)
|
||||
- a coin. He turned to me next with the same sunny smile. Looking at the lute case I carried he cocked an eyebrow at me. “Good to see a new face. You know the rules?” I nodded and handed him a jot. He turned to point inside. “You see the bar?” It was hard to miss fifty feet of winding mahogany that curved through the far end of the room. “See where the (Location 6594)
|
||||
- with the hand that wasn’t holding an impressively tall tankard. (Location 6632)
|
||||
- steal your heart. Men fall for her like wheat before a sickle (Location 7447)
|
||||
- to my stomach. This was exactly what I’d hoped to avoid: an opportunity for both Ambrose and Hemme to settle scores with me. Worse still, this was bound to lower Lorren’s opinion of me even further, no matter what the outcome. I arrived in the Masters’ Hall early and was relieved to find the atmosphere much more relaxed than when I’d gone on the horns for malfeasance against Hemme. Arwyl and Elxa Dal smiled at me. Kilvin nodded. I was relieved that I had friends among the masters to balance out the enemies I’d made. “Alright,” the Chancellor said briskly. “We’ve (Location 7629)
|
||||
- I spotted Manet off in the corner, loading tile into a kiln. (Location 8041)
|
||||
- “The truth is deeper than that. It’s…” Bast floundered for a moment. “It’s like everyone tells a story about themselves inside their own head. Always. All the time. That story makes you what you are. We build ourselves out of that story.” (Location 12228)
|
||||
@@ -0,0 +1,18 @@
|
||||
# The Sixth Extinction
|
||||
|
||||
|
||||
|
||||
## Metadata
|
||||
- Author: [[Elizabeth Kolbert]]
|
||||
- Full Title: The Sixth Extinction
|
||||
- Category: #books
|
||||
|
||||
## Highlights
|
||||
- Although a land animal, our species—ever inventive—crosses (Location 57)
|
||||
- zeteki. Golden frogs have a distinctive, ambling gait (Location 141)
|
||||
- “Corals build the architecture of the ecosystem,” Caldeira told me. “So it’s pretty clear if they go, the whole ecosystem goes.” One of the Israeli scientists, Jack Silverman, put it to me this way: “If you don’t have a building, where are the tenants going to go?” (Location 1932)
|
||||
- Ocean acidification is, of course, not the only threat reefs are under. Indeed, in some parts of the world, reefs probably will not last long enough for ocean acidification to finish them off. The roster of perils includes, but is not limited to: overfishing, which promotes the growth of algae that compete with corals; agricultural runoff, which also encourages algae growth; deforestation, which leads to siltation and reduces water clarity; and dynamite fishing, whose destructive potential would seem to be self-explanatory. All of these stresses make corals susceptible to pathogens. (Location 1947)
|
||||
- “This is a qualitatively different set of stresses that we are putting on species,” Silman told me. “In other kinds of human disturbances there were always spatial refuges. Climate affects everything.” Like ocean acidification, it is a global phenomenon, or, to borrow from Cuvier, a “revolution on the surface of the earth.” (Location 2354)
|
||||
- “If evolution works the way it usually does,” Silman said, “then the extinction scenario—we don’t call it extinction, we talk about it as ‘biotic attrition,’ a nice euphemism—well, it starts to look apocalyptic.” (Location 2386)
|
||||
- Using the species-area relationship, S = cAz, and setting the value of z at .25, we can calculate that losing one percent of the original area implies the loss of roughly a quarter of a percent of the original species. If we assume, very conservatively, that there are two million species in the tropical rainforests, this means that something like five thousand species are being lost each year. This comes to roughly fourteen species a day, or one every hundred minutes. (Location 2568)
|
||||
- altruistic. Time and time again, people have demonstrated (Location 3598)
|
||||
@@ -0,0 +1,12 @@
|
||||
# The Wise Man's Fear
|
||||
|
||||
|
||||
|
||||
## Metadata
|
||||
- Author: [[Rothfuss, Patrick]]
|
||||
- Full Title: The Wise Man's Fear
|
||||
- Category: #books
|
||||
|
||||
## Highlights
|
||||
- It had flaws, but what does that matter when it comes to matters of the heart? We love what we love. Reason does not enter into it. In many ways, unwise love is the truest love. Anyone can love a thing because. That’s as easy as putting a penny in your pocket. But to love something despite. To know the flaws and love them too. That is rare and pure and perfect. (Location 1171)
|
||||
- As with many things, hesitation is better than hurry. (Location 2004)
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
Rezepttyp: Apero
|
||||
---
|
||||
|
||||
|
||||
Für 6 Personen
|
||||
|
||||
# Dressing
|
||||
|
||||
| 1 | TL | Limonenschale | fein geraspelt |
|
||||
| --- | --- | ------------------- | ------------------------------------------ |
|
||||
| 2 | EL | Limonensaft | |
|
||||
| 1 | TL | brauner Zucker | |
|
||||
| 1 | EL | Olivenöl | |
|
||||
| 2-3 | | (Jalapeno) Chillies | entkernt und geschnitten |
|
||||
| | | | alles in einer kleinen Schüssel vermischen |
|
||||
|
||||
# Zubereitung
|
||||
2 reife Avocados geschält und in Scheiben geschnitten mit dem Dressing servieren
|
||||
|
||||
Tipp:
|
||||
Es hält sich 2-3 Tage zugedeckt im Kühlschrank, Limonensaft verhindert, dass die Avocado braun wird.
|
||||
Die Avocado kann auch gewürfelt oder mit einem Melonenschneider kugelförmig ausgestochen werden
|
||||
@@ -0,0 +1,404 @@
|
||||
---
|
||||
title: Design Patterns by Construx
|
||||
created_date: 2025-01-16
|
||||
updated_date: 2025-01-16
|
||||
aliases:
|
||||
tags:
|
||||
- course
|
||||
type: course
|
||||
course_name: Design Patterns
|
||||
author: Construx
|
||||
source: https://construx.vueocity.com/portal/design-patterns
|
||||
status: not_started
|
||||
---
|
||||
# Design Patterns by Construx
|
||||
- **🏷️Tags** : #01-2025 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the course to someone else?
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other resources?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
|
||||
---
|
||||
## Introduction
|
||||
### Getting Started
|
||||
|
||||
> [!definition] UML Notation
|
||||
> Contents
|
||||
|
||||
> [!Definition] What is a Design Pattern
|
||||
> A standard solution to a recurring problem.
|
||||
>
|
||||
> We should not reinvent the wheel. Patterns are much more reusable than code.
|
||||
|
||||
A *bridge* is a design pattern because it is a standard solution to a recurring problem: we need to get things across a not passable obstacle.
|
||||
For every problem you have *design criteria* to choose the best type of bridge (e.g. span, clearance, loads, cost, etc.). In design patterns design criteria are called *Goal forces* and *constraint forces*.
|
||||
As a beginner: focus on the problem, not the solutions!
|
||||
|
||||
### UML Notations:
|
||||
#### Note
|
||||
![[Pasted image 20250116161217.png]]
|
||||
#### Class, Attribute and Operation
|
||||
![[Pasted image 20250116160836.png]]
|
||||
|
||||
Operations are viewed from extern
|
||||
Methods are viewed from intern
|
||||
|
||||
### Minimize Overall Complexity
|
||||
Measures of complexity
|
||||
- Cyclomatic complexity: the number of decisions that are being made --> local complexity
|
||||
- Depth of decision making: embedding of decision within decision and decision --> local complexity
|
||||
- number of parameters: --> global complexity
|
||||
- fan out: number of functions that are called by the function --> global complexity
|
||||
|
||||
![[Pasted image 20250116161534.png]]
|
||||
|
||||
Local complexity is a measure on how complicated each function is, whereas the global complexity is the complexity in between functions.
|
||||
Remember to get an appropriate balance.
|
||||
|
||||
### Use Abstractions
|
||||
**Syntax**: Is all about structure
|
||||
**Semantics**: Is all about meaning
|
||||
|
||||
- Colorless green dreams sleep furiously: correct syntax, completely wrong semantics --> defective or buggy code, because it is semantically meaningless
|
||||
|
||||
The *compiler* is a master of syntax but cannot know anything about semantics.
|
||||
The programmer needs to focus much more on semantics, because the complier will take care of the syntax.
|
||||
|
||||
> [!NOTE] Abstraction
|
||||
> the principle of ignoring those aspects of a subject that are not relevant to the current purpose in order to concentrate solely on those that are.
|
||||
>
|
||||
> It is a tool to reduce and manage complexity.
|
||||
|
||||
what is the role of one function / subroutine? The more abstraction you have, the less performant the code becomes.
|
||||
Abstraction is not learnable. Good abstractions lead to clean code, which is maintainable and leads to less defects.
|
||||
|
||||
### Encapsulate Design Decisions
|
||||
Abstraction: permission to ignore
|
||||
Encapsulation: I prevent you from knowing
|
||||
Meaning they are not the same thing.
|
||||
|
||||
Goal:
|
||||
- **hide design decision** (data representation, algorithms, etc.)
|
||||
- **Modules should be black boxes**: programm to an interface, not through an interface
|
||||
|
||||
Idea: Design by Contract
|
||||
Requires vs Guarantees
|
||||
A function promises to give certain outputs depending on the inputs
|
||||
This is important for documentation of code if the code is used by different people. Docstrings for example.
|
||||
We only worry about semantic things. Explain exactly what the input values should be and what the return values will be. Explain exactly what errors and exceptions. Include Constraints on state (function may open file), include performance limits (use no more than 200 bytes per instance, etc).
|
||||
Defensive contract: requires less and guarantees more (check input for example).
|
||||
Contracts are great, because you can treat the function as a blackbox. When you modify the contract you need to inform all the users of the function about the updates of the contract
|
||||
|
||||
**Desing by Contract is the means to encapsulation**
|
||||
Use: **Purpose, Requires and Guarantees**
|
||||
|
||||
### Maximize Cohesion, Minimize Coupling
|
||||
**Cohesion**: Indivisibility of a given part: Does this function do exactly one thing? It should also not split functionality into two separate functions
|
||||
**Coupling**: Dependence between parts: Do not connect things that don't need to be connected. If you must connect things, connect them such that they can be disconnected as easily as possible.
|
||||
|
||||
Goal: Highly cohesive, very loosely coupled
|
||||
|
||||
Generally software solves problems by *Decomposition, solution, recomposition*. There are an infinite amount of different solutions, which have different quality. Cohesion and Coupling characterise the quality of the solution.
|
||||
|
||||
![[Pasted image 20250116171230.png]]
|
||||
|
||||
Always try to Decouple code:
|
||||
|
||||
| **Avoid** | **Do** |
|
||||
| ----------------------------------- | -------------------------------------------------------------------------------------------------------- |
|
||||
| Global variables (form of coupling) | Design by Contract |
|
||||
| Friend (C++) | Dependency inversion: if you depend on things, depend on the most generic thing (type of car, not model) |
|
||||
| Self-modifying code | Publish-subscribe (observer pattern) |
|
||||
| Reflection | Law of Demeter |
|
||||
#### Law of Demeter
|
||||
Principle of least knowledge.
|
||||
a.b().c() breaks the law --> violates coupling
|
||||
a.b() doesn't break the law
|
||||
|
||||
### Design to Invariants, Design for Change
|
||||
Product Families: attack different target markets with different value propositions with the same base platform: (pickup truck and SUV example. For ford it's the same car (slight difference in build but 95% the same)).
|
||||
The **core of the software design is made for the invariants**, meaning all the things that do not change and are the same throughout the software. An example might be the base driver code and the base I2C/SPI interface, which all the drivers use. Every driver has different registers that need to be set with different values, but the core structure can be designed to be invariant.
|
||||
Design for Change means the same thing: to *separate common from variable functionality*: use templates, inheritance, conditional compilation, frameworks.
|
||||
*Hide variation behind abstract interfaces*: Outside sees a routine that moves data from A to B and doesn't care how it is being done. It can be done by ftp, scp, tcp/ip, bluetooth, etc. Design patterns that make abstract interfaces are adapter, bridge, strategy, factory method, abstract factory, template method, iterator, decorator, proxy, etc. The client side code does not need to be changed when the bridge implementation changes.
|
||||
*Use delayed-binding strategies*: C does early binding, python does very late binding. Examples: named constants, configuration/preference files, dependency injection/ function pointers, inversion of control, data-driven design (set of data to configure software, e.g xml files or so?), self-configuration (android: different hardware configurations. It pings the hardware upon boot and asks about specifications of the hardware.). A problem is that usually software is developed sequentially: first for customer A, then customer B, etc. Better would be to find out about more about the landscape before starting the development.
|
||||
|
||||
### UML: Association and Multiplicity
|
||||
**Association**: represents links between objects
|
||||
**Multiplicity**: constraints on number of links
|
||||
![[Pasted image 20250117100749.png]]
|
||||
|
||||
Multiplicity: 1 to many. If you are a customer must you have at least 1 order? The
|
||||
\*-Notation means that it can also be 0. There are four cases which are noted differently:
|
||||
|
||||
| Lower Bound | Upper Bound | UML Notation |
|
||||
| ----------- | ----------- | ------------ |
|
||||
| 0 | 1 | 0..1 |
|
||||
| 0 | Many | \* |
|
||||
| 1 | 1 | 1 |
|
||||
| 1 | Many | 1..\* |
|
||||
Note that it can also be specific numbers: e.g. 3..7
|
||||
#### UML Notation: Composition and Aggregation
|
||||
Composition: exclusive membership: ♦
|
||||
Aggregation: non-exclusive membership: ♢
|
||||
When using composition and aggregation, be specific about the multiplicity.
|
||||
Diamonds are trendy and are often misused: you can specify multiplicity to represent the exact same thing as composition and aggregation.
|
||||
|
||||
### UML: Sequence Diagram
|
||||
Describes interactions between objects (dynamics).
|
||||
Primary Concepts: Objects, lifeline, activation context, message
|
||||
Naming: objectName:class, objectName, :class
|
||||
|
||||
![[Pasted image 20250117102354.png]]
|
||||
---- is the lifeline
|
||||
time goes from top to bottom
|
||||
opt: optional
|
||||
\[too cold] is a condition
|
||||
|
||||
|
||||
### UML: Inheritance and Abstraction
|
||||
An arrow pointing to the base class is done by Inheritance
|
||||
![[Pasted image 20250117102805.png]]
|
||||
|
||||
An abstract class is a base class, which itself cannot create any objects, have any instances. It just creates an interface. If shape was abstract you could only create rectangles and circles, but no other shapes. Abstract methods within abstract classes need to be implemented
|
||||
|
||||
### Design Principle: Liskov Substitutability
|
||||
|
||||
T (superclass) <-- S (subclass)
|
||||
Goal: objects of class T may be replaced with objects of class S without altering any desirable properties of that program (e.g. correctness)
|
||||
- preconditions in subclass S as strict or less strict than in superclass T
|
||||
- postconditions in subclass S as strict or less strict than in superclass T
|
||||
- No new exceptions should be introduced in subclass S
|
||||
--> A subclass S must require no more and promise no less than its superclass T
|
||||
|
||||
Example: the contract requires must be the same or less strict (preconditions) and for the guarantees the subclass must guarantee the same or more than the superclass T (postconditions)
|
||||
|
||||
Be cautious about *accidental polymorphisms*: a completely different class that uses the same names. Usually the requires and guarantees are very different. This means syntax is the same, but semantics are different. Syntactically substitutionable but not semantically substitubable.
|
||||
|
||||
#### Design Principle: Favor Association over Inheritance
|
||||
Inheritance cannot change the behaviour at run-time: a rectangle shape cannot morph into a circle shape.
|
||||
|
||||
## Design Patterns
|
||||
Patterns are not mutually exclusive and can be used on top of each other.
|
||||
|
||||
|
||||
### Adapter Pattern
|
||||
- No prerequisits
|
||||
- Usually problems have same semantic, but a different syntax.
|
||||
- Reasons: too much client code to change, code not accessible, many clients that use the same code
|
||||
- Adapters are an intermediate code block that adapts the syntax between the two parts.
|
||||
- meaning you have one more layer, thus slightly less performance.
|
||||
- ![[Pasted image 20250117112716.png]]
|
||||
- use an adapter base class (PCLinuxGraphicsAdapter)
|
||||
- There is no guarantee that it is only the syntax that changes, maybe you need to adapt the semantics as well.
|
||||
- Object vs class adaption.
|
||||
- In multiple inheritance classes like C++ you inherit from both Target and Adaptee
|
||||
- ![[Pasted image 20250117115604.png]]
|
||||
- Relationship to fundamental design principles
|
||||
- design to invariants/desing for change
|
||||
- encapsulation
|
||||
- liskov substitutability
|
||||
- high cohesion/loose coupling
|
||||
|
||||
|
||||
> [!Important] Key Points
|
||||
> - minimizes code changes
|
||||
> - portability across multiple providers
|
||||
> - two versions: object vs class adapter
|
||||
|
||||
Interesting application:
|
||||
In testing you might want to test hidden / private functions. So you can create a inherited object lets call it test-object, where those functions are exposed. So the test-object is basically an adapter.
|
||||
### Façade (also called Wrapper)
|
||||
Build a wrapper around a complex service to simplify the interface.
|
||||
- Depending on the language you might not be able to preventing the client to go around the facade.
|
||||
- An adapter can be a wrapper. It all depends on your intent:
|
||||
If your intent is syntax adapting it is an adapter.
|
||||
If your intent is hiding complexity it is a wrapper.
|
||||
It can be both at the same time if your intent is to do both at the same time
|
||||
|
||||
#### Design principles
|
||||
- Encapsulation
|
||||
- Abstraction (hide details that are not needed)
|
||||
- High cohesion / loose coupling (secondary, decouple the service provider)
|
||||
### Bridge
|
||||
**Prerequisite**: Adapter Pattern
|
||||
The bridge pattern is very dynamic and can be changed during runtime very quickly (strategy pattern is more static.)
|
||||
Remember the fundamental design pattern of favouring association over inheritance. In a CNC-milling machine example we have 60 different subclasses of a programStep, which all cut different cuts. If I want to add a new communication protocol to communicate with the machine (tcp instead of serial) I would have to add another layer which adds another 60 subclasses, and so forth. This would be really bad and this is where the bridge pattern thrives:
|
||||
|
||||
Goal force: decouple abstraction from implementation so that the two can vary independently. There are variations on two dimensions: the type of cut, the type of communication.
|
||||
Constraint force: layer of indirection: slight performance hit
|
||||
|
||||
**Abstraction and Implementation can vary independently!**
|
||||
|
||||
![[Pasted image 20250117141550.png]]
|
||||
|
||||
Bridge is often inherently an Adapter.
|
||||
|
||||
> [!NOTE] No definition of how "abstractions" get bound to "implementors"
|
||||
> - statically at "abstraction" instantiation
|
||||
> - dynamically as parameter or dependency injection?
|
||||
|
||||
#### Design principles
|
||||
- favor association over inheritance
|
||||
- high coehision/ loose coupling
|
||||
- design to invariants / design for change
|
||||
- liskov substitutability
|
||||
|
||||
![[Pasted image 20250117142732.png]]
|
||||
### Strategy
|
||||
Forces:
|
||||
- behavior needs to change at runtime
|
||||
- support different solutions to a particular problem
|
||||
- insulate clients from details of the solutions
|
||||
- added layer of indirection is acceptable (hit on performance)
|
||||
|
||||
![[Pasted image 20250117152338.png]]
|
||||
|
||||
|
||||
> [!NOTE] Implementation Note
|
||||
> No definition of how nor when "context" gets bound to "concrete strategies"
|
||||
> - client decides
|
||||
> - broker or agent decides
|
||||
> - parameter
|
||||
> - dependency injection
|
||||
>
|
||||
> Concrete strategies need identical interface but maybe not the same parameters
|
||||
|
||||
Example: sorting algorithms
|
||||
different sorting algorithms have different properties. Strategy design pattern can be used to let clients use different sort algorithms
|
||||
|
||||
#### Design principles
|
||||
- design to invariants / design for change
|
||||
- encapsulation
|
||||
- liskov substitutability
|
||||
- high cohesion / loose coupling
|
||||
|
||||
> [!Important] Key Points
|
||||
> Strategy defines family of algorithms, encapsulates each one and makes them interchangable
|
||||
|
||||
### Composite
|
||||
No prerequisite
|
||||
Allows to use recursion: example: make folders inside folders inside folders
|
||||
|
||||
#### Forces
|
||||
- need to represent hierarchical structures
|
||||
- need to treat primitive elements and composites as uniformly as possible
|
||||
- copying, moving, deleting files has same effect as on folder
|
||||
- resizing one shape on drawing has same effect as resizing group of shapes
|
||||
What you can do with an individual you should do with a group
|
||||
|
||||
![[Pasted image 20250117153232.png]]
|
||||
![[Pasted image 20250117153316.png]]
|
||||
|
||||
|
||||
> [!NOTE] Implementation Notes
|
||||
> - depth first vs breadth-first might be relevant in operations that traverse structure.
|
||||
> - ordering of compoonents in composite might be relevant
|
||||
> - shallow copy vs deep copy (**implement in contract! Should be crystal clear**)
|
||||
> - **shallow**: Only immediate object copied, not sub-referenced objects
|
||||
> - **deep**: copy object and all sub-referenced objects.
|
||||
|
||||
#### Design Principles
|
||||
- Abstraction
|
||||
- Design to invariants/design for change
|
||||
- encapsulation
|
||||
- liskov substitutability
|
||||
- high cohesion / loose coupling
|
||||
|
||||
> [!Important] Key Points
|
||||
> - hierarchical structure
|
||||
> - treat primitive elementss and composites as uniformly as possible
|
||||
> - copying, moving, deleting
|
||||
> - resizing single shape has same effect as resizing multiple grouped shapes
|
||||
> - be careful with copy() semantics --> communicate through contract
|
||||
|
||||
### Observer aka. Publish-Subscribe
|
||||
prerequisites: None
|
||||
aka: Implicit Invocation, Publish-Subscribe
|
||||
|
||||
Forces:
|
||||
- 1-to-many dependency requiring object to notify many other objects when it changes state
|
||||
- need to limit direct knowledge the many and the one have of each otehr
|
||||
- added layer of indirection is acceptable (performance hit)
|
||||
|
||||
![[Pasted image 20250117160123.png]]
|
||||
|
||||
|
||||
> [!Note] Implementation Notes
|
||||
> - same notification interface for all observers on same subject (even if information needs are different)
|
||||
> - update() might carry new the updated data, or its just a ping and the observer needs to pull upon the notification
|
||||
> - no control over the order
|
||||
> - subject may need prevent modification of state until all observers were notified
|
||||
> - implementation is an interface and not a base class
|
||||
|
||||
Observer design patterns are often used with model-view-controller architectures
|
||||
![[Pasted image 20250117162946.png]]
|
||||
|
||||
Variation on the theme: Event Channel: many publishers and many subscribers
|
||||
#### Design Principles
|
||||
- high cohesion / loose coupling
|
||||
- design to invariants / design for change
|
||||
- encapsulation
|
||||
|
||||
|
||||
|
||||
> [!NOTE] Key Points
|
||||
> - pattern allows to notify many others when state changes
|
||||
> - decoupling of information provider from information consumers
|
||||
> - state data can be pushed on update() or pulled by observers
|
||||
> - event channels (variant) supports many publishers and many subscribers on the same channel
|
||||
|
||||
### Template Method
|
||||
Prerequisite: Stategy
|
||||
`#ifdef do this` can be replaced with the template method.
|
||||
|
||||
#### Pattern Forces
|
||||
Need to define skeleton of algorithm but defer some details:
|
||||
- make abstract class easier by reminding developers to supply logic for all situation-specific details
|
||||
Added layer of indirection is acceptable
|
||||
|
||||
#### Design Principles
|
||||
|
||||
|
||||
> [!Note] Key Points
|
||||
> Contents
|
||||
|
||||
|
||||
### Factory Method
|
||||
|
||||
### Abstract Factory
|
||||
|
||||
### Singleton
|
||||
|
||||
### Iterator
|
||||
|
||||
### Proxy
|
||||
|
||||
### Decorator
|
||||
|
||||
### Command
|
||||
|
||||
### State
|
||||
|
||||
### Data Access Object
|
||||
|
||||
---
|
||||
## Exercises
|
||||
|
||||
---
|
||||
```query
|
||||
Design Patterns Construx
|
||||
-file: "Design Patterns by Construx.md"
|
||||
```
|
||||
Reference in New Issue
Block a user