vault backup: 2025-02-03 08:29:48
This commit is contained in:
Binary file not shown.
Binary file not shown.
279
5 Media/0 Books/More Effective Agile by Steve McConnell.md
Normal file
279
5 Media/0 Books/More Effective Agile by Steve McConnell.md
Normal file
@@ -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,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"
|
||||
```
|
||||
51
5 Media/0 Books/Surrounded by Idiots by Thomas Erikson.md
Normal file
51
5 Media/0 Books/Surrounded by Idiots by Thomas Erikson.md
Normal file
@@ -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"
|
||||
```
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
14
5 Media/6 Readwise/Books/25 Year Framework.md
Normal file
14
5 Media/6 Readwise/Books/25 Year Framework.md
Normal file
@@ -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)
|
||||
34
5 Media/6 Readwise/Books/Shantaram.md
Normal file
34
5 Media/6 Readwise/Books/Shantaram.md
Normal file
@@ -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)
|
||||
20
5 Media/6 Readwise/Books/The Name of the Wind.md
Normal file
20
5 Media/6 Readwise/Books/The Name of the Wind.md
Normal file
@@ -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)
|
||||
18
5 Media/6 Readwise/Books/The Sixth Extinction.md
Normal file
18
5 Media/6 Readwise/Books/The Sixth Extinction.md
Normal file
@@ -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)
|
||||
404
5 Media/8 Courses/Design Patterns by Construx.md
Normal file
404
5 Media/8 Courses/Design Patterns by Construx.md
Normal file
@@ -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