Chapter 1 - The problem with org charts

Modern IT organizations must deliver and operate software systems rapidly and safely, while simultaneously growing and adapting changes and pressures in the business or regulatory environment

Communication Structures of an Organization

It usually shows hierarchical lines of reporting, which imply lines of communication running “up and down” the organization.

In reality people don’t restrict their communications only to those connected lines on the chart. They reach out to whomever we depend on to get work done. They bend the rules when required to achieve our goals. That’s why actual communication lines look quite different from the org chart

Org Chart Thinking Is the Problem

Decisions based on org-chart structure tend to optimize for only part of the organization, ignoring upstream and downstream effects. Local optimizations help the teams directly involved, but they don’t necessarily help improve the overall delivery of value to customers. For example, having teams adopting cloud and infrastructure-as-code can reduce the time to provision new infrastructure from weeks or months to minutes or hours. But if every change requires deployment (to production) approval from a board that meets once a week, then delivery speed will remain weekly at best.

Thinking of the org chart as a faithful representation of how work gets done and how teams interact with each other leads to ineffective decisions around allocation of work and responsibilities. Much like a software architecture document gets outdated as soon as the actual software development starts, an org chart is always out of sync with reality.

So if org charts are not an accurate representation of organizational structures, what is? Niels Pflaeging, author of Organize for Complexity, identifies not one but three different organizational structures in every organization:?

1. Formal structure (the org chart)—facilitates compliance
2. Informal structure—the “realm of influence” between individuals
3. Value creation structure—how work actually gets done based on inter-personal and inter-team reputation

Team Topologies: A New Way of Thinking about Teams

Team Topologies provides four fundamental team types—stream-aligned, platform, enabling, and complicated-subsystem—and three core team interaction modes —collaboration, X-as-a-Service, and facilitating. Together with awareness of Conway’s law, team cognitive load, and how to become a sensing organization, Team Topologies results in an effective and humanistic approach to building and running software systems.

The Revival of Conway’s Law

What is conway’s Law :

“Organizations which design systems .. . are constrained to produce designs which are copies of the communication structures ofthese organizations.”

Chapter 2: Conway’s Law and Why It Matters”.

Chapter 3: Team-First Thinking

Google on their own teams found that who is on the team matters less than the team dynamics; and that when it comes to measuring performance, teams matter more than individuals.? We must, therefore, start with the team for effective software delivery. There are multiple aspects to consider and nurture: team size, team lifespan, team relationships, and team cognition.

Use Small, Long-Lived Teams as the Standard

Team has a very specific meaning. By team, we mean a stable grouping of five to nine people who work toward a shared goal as a unit. In most organizations, an effective team has a maximum size of around seven to nine people. Dunbar found fifteen to be the limit of the number of people one person can trust deeply.” From those, only around five people can be known and trusted closely.

Allowing teams to grow beyond the magic seven-to-nine size imperils the viability of the software being built by that team, because trust will begin to break down and unsuitable decisions might ensue. Organizations need to maximize trust between people on a team, and that means limiting the number of team members

Work Flows to Long-Lived Teams

Typically, a team can take from two weeks to three months or more to become a cohesive unit. When (or if) a team reaches that special state, it can be many times more effective than individuals alone. If it takes three months for a team to become highly effective, we need to provide stability around and within the team to allow them to reach that level. Typically, a team can take from two weeks to three months or more to become a cohesive unit. When (or if) a team reaches that special state, it can be many times more effective than individuals alone. Adding new people to a team doesn’t immediately increase its capacity as there is emotional adaption to accommodate each other view points.

Team owns the Software

Teams may use shared services at runtime, but every running service, application, or subsystem is owned by only one team. Awareness of and ownership over these different time horizons helps a team care for the code more effectively.

Team Members Need a Team-First Mindset

Team members should put the needs of the team above their own. They should:

• Arrive for stand-ups and meetings on time.
• Keep discussions and investigations on track.

Encourage a focus on team goals.

Help unblock other team members before starting on new work. Mentor new or less experienced team members.

Avoid “winning” arguments and, instead, agree to explore options.

Embrace Diversity in Teams

Members of diverse backgrounds tend to produce more creative solutions more rapidly and tend to be better at empathizing with other teams’ needs.!” How ? In the context of discovering new possibilities, having a variety of viewpoints and experiences helps teams traverse the landscape of solutions much more rapidly. As Naomi Stanford, author of Guide to Organisation Design, puts it: “people and organizations benefit from a diverse workforce where differences spark positive energy.”

Good Boundaries Minimize Cognitive Load

Restrict Team Responsibilities to Match Team Cognitive Load

Ever-increasing size and complexity of codebases that teams have to work with. This creates an unbounded cognitive load on teams. Also applies to teams like a operations or infrastructure team. They can also suffer from excessive cognitive load in terms of domains of responsibility, number of applications they need to operate, and tools they need to manage.

For software-delivery teams, a team-first approach to cognitive load means limiting the size of the software system that a team is expected to work with; that is, organizations should not allow a software subsystem to grow beyond the cognitive load of the team responsible for the software.

Kinds of cognitive load:

• Intrinsic cognitive load—trelates to aspects of the task fundamental to the problem space (e.g., “What is the structure of a Java class?” “How do I create a new method?”)

• Extraneous cognitive load—relates to the environment in which the task is being done (e.g., “How do I deploy this component again?” “How do I configure this service?”)

• Germane cognitive load—relates to aspects of the task that need special attention for learning or high performance (e.g., “How should this service interact with the ABC service?”)

Many organizations do not consider the cognitive load on teams when assigning responsibility for parts of a software system, instead assuming that by adding more teams to the problem, the cognitive load will be shared across the teams. Instead, the teams will suffer from similar communication and interaction strains

If we stress the team by giving it responsibility for part of the system that is beyond its cognitive load capacity, it ceases to act like a high-performing unit and starts to behave like a loosely associated group of individuals, each trying to accomplish their individual tasks without the space to consider if those are in the team’s best interest.

Measure the Cognitive Load Using Relative Domain Complexity

“Do you feel like you’re effective and able to respond in a timely fashion to the work you are asked to do?” Tying to determine the cognitive load of software using simple measures such as lines of code, number of modules, classes, or methods is misguided.

1. The first heuristic is to assign each domain to a single team. If a domain is too large for a team, instead of splitting responsibilities of a single domain to multiple teams, first split the domain into subdomains and then assign each new subdomain to a single team.
2. The second heuristic is that a single team (considering the golden seven-to-nine team size) should be able to accommodate two to three “simple” domains. Because such domains are procedural, the cost of context switching between domains is more bearable
3. The third heuristic is that a team responsible for a complex domain should not have any more domains assigned to them—not even a simple one. The last heuristic is to avoid a single team responsible for two complicated domains.

Match Software Boundary Size to Team Cognitive Load

Instead of choosing between a monolithic architecture or a microservices architecture, design the software to fit the maximum team cognitive load. Only then can we hope to achieve sustainable, safe, rapid software delivery. This team-first approach to software boundaries leads to favoring certain styles of software architecture, such as small, decoupled services.

1. Provide a team-first working environment (physical or virtual).
2. Minimize team distractions during the workweek by limiting meetings, reducing emails, assigning a dedicated team or person to support queries, and so forth.
3. Change the management style by communicating goals and outcomes rather than obsessing over the “how”
4. Increase the quality of developer experience (DevEx) for other teams using your team’s code and APIs through good documentation, consistency, good UX, and other DevEx practices.
5. Use a platform that is explicitly designed to reduce cognitive load for teams building software on top of it.

Minimize cognitive load for others” is one of the most useful heuristics for good software development.

Define “Team APIs” that Include Code, Documentation, and User

The team API should explicitly consider usability by other teams: Will other teams find it easy and straightforward to interact with us, or will it be difficult and confusing? How easy will it be for a new team to get on board with our code and working practices? How do we respond to pull requests and other suggestions from other teams? Is our team backlog and product roadmap easily visible and understandable by other teams? For effective team-first ownership of software, teams need to continuously define,advertise, test, and evolve their team API to ensure that it is fit for purpose for the consumers of that API: other teams/memebers.

The team API includes:

1. Code: runtime endpoints, libraries, clients, UI, etc. produced by the team
2. Versioning: how the team communicates changes to its code and services (e.g., using emantic versioning [SemVer] as a “team promise” not to break things)
3. Wiki and documentation: especially how-to guides for the software owned by the team
4. Practices and principles: the team’s preferred ways of working
5. Communication: the team’s approach to remote communication tools, such as chat tools and video conferencing
6. Work information: what the team is working on now, what’s coming next, and overall priorities in the short to medium term
7. Anything else that other teams need to use to interact with the team

Facilitate Team Interactions for Trust, Awareness, and Learning

(1) a consciously designed physical and virtual environment; and (2) time away from desks at guilds, communities of practice (a group of people who regularly get together on a voluntary basis to collectively learn and share knowledge about a domain of interest, internal tech conferences, etc.

Explicitly Design the Physical and Virtual Environments to Help Team Interactions

Neither individual cubicles nor fully open-plan seating is generally suitable for teams . We need something better. Teams need the ability to collaborate frequently, internally and only occasionally externally (with other teams). This balance is hard to achieve both in an open-plan layout (no dedicated work area for the team) and in an individual- workspaces layout (time together needs to be planned ahead of time and meeting rooms are often scarce). Example : Spotify—talked about how “squads in a tribe are all physically in the same office, normally right next to each other, and the lounge areas nearby promote collaboration between the squads.”°

Office design for effective software delivery should accommodate all of the following modes of work: focused individual work, collaborative intra-team work, and collaborative inter-team work.

Warning: Engineering Practices Are Foundational

At the end of the day, technology teams need to invest in proven team practices like continuous delivery, test-first development, and a focus on software operability and releasability. Without them, all the effort invested in a team-first approach to work and flow will be greatly undermined.

Chapter 4 Static team topologies

Team Anti-Patterns

The first anti-pattern is ad hoc team design. This includes teams that have grown too large and been broken up as the communication overhead starts taking a toll. The other common anti-pattern is shuffling team members. This leads to extremely volatile team assembled on a project basis and disassembled immediately afterward, perhaps leaving one or two engineers behind to handle the “hardening” and maintenance phases of the application(s).

Organizations must design teams intentionally by asking these questions: Given our skills, constraints, cultural and engineering maturity, desired software architecture, and business goals, which team topology will help us deliver results faster and safer?

Design for Flow of Change

Technical staff at Spotify are arranged into small, autonomous, cross-functional squads, each with a long-term mission and comprised of around five to nine people. Several squads that work on similar areas are collected into a tribe, a sort of affinity grouping of squads. The squads within a tribe are familiar with the work of other squads and coordinate inside the tribe.

Engineers within a tribe with similar skills and competencies share practices through a chapter. So, for example, all the testers across six squads in a tribe could be part of a testers chapter. Line management also happens via chapters, but the line manager (the chapter lead) is also part of the day-to-day work of a squad, not an aloof manager. Spotify also uses a more diffuse “guild,” akin to a community of practice, that can include people from across multiple tribes, chapters, and squads. “Chapters and guilds . . . [are] the glue that keeps the company together, [providing] economies of scale without sacrificing too

Shape Team Intercommunication to Enable Flow and Sensing

organizations seem to assume that software delivery is a one-way process, leading from specification to design, from design to coding, from coding to testing and releasing, and from releasing to business as usual (BAU) operation

Assumption that the software-development process has little or nothing to learn from how the software runs in the live environment is fundamentally flawed. On the contrary, organizations that expose software-development teams to the software running in the live environment tend to address user-visible and operational problems much more rapidly compared to their siloed competitors

we must . . . ensure delivery teams are cross-functional, with all the skills necessary to design, develop, test, deploy, and operate the system on the same team.”

Organizations that value information feedback from live (production) systems can not only improve their software more rapidly but also develop a heightened responsiveness to customers and users.

DevOps and the DevOps Topologies

“wall of confusion.” - > In dev ops word when with software releases being thrown over the “fence” or “wall” and communication mostly accomplished through tickets

The problem was that many organizations adopting Agile were not explicitly addressing the gap between software delivery speed and operations teams’ capacity to provide resources or deploy updates. The misalignment between teams became more and more evident, leading to poor behaviors and lack of focus on the flow of work.

DevOps Topologies

The DevOps Topologies reflect two key ideas: (1) There is no one-size-fits-all approach to structuring teams for DevOps success. The suitability and effectiveness of any given topology depends on the organization’s context. (2) There are several topologies known to be detrimental (anti-patterns) to DevOps success, as they overlook or go against core tenets of DevOps. In short, there is no “right” topology, but several “bad” topologies for any one organization.

Successful Team Patterns

Feature Teams Require High-Engineering Maturity and Trust

We consider a feature team to be a cross- functional, cross-component team that can take a customer facing feature from idea all the way to production, making them available to customers and, ideally, monitoring its usage and performance. Are these a pattern or an anti-pattern? As you might have guessed by now, it depends.

A cross-functional feature team can bring high value to an organization by delivering cross-component, customer-centric features much faster than multiple component teams making their own changes and synchronizing into a single release. But this can only happen when the feature team is self-sufficient, meaning they are able to deliver features into production without waiting for other teams.

The feature team typically needs to touch multiple codebases, which might be owned by different component teams. If the team does not have a high degree of engineering maturity, they might take shortcuts, such as not automating tests for new user workflows or not following the “boy-scout rule” (leaving the code better than they found it). Over time, this leads to a breakdown of trust between teams as technical debt increases and slows down delivery speed.

Product Teams Need a Support System

The key for the team to remain autonomous is for external dependencies to be non-blocking, meaning that new features don’t sit idle, waiting for something to happen beyond the control of the team. For example, it’s extremely difficult to ensure that a separate QA team will be available to evaluate a new feature exactly when the product team finishes it. Non-blocking dependencies often take the form of self-service capabilities (e.g, around provisioning test environments, creating deployment pipelines, monitoring, etc.) developed and maintained by other teams. These can be consumed independently by the product teams when they need them.

Cloud Teams Don’t Create Application Infrastructure

Product teams need autonomy to provision their own environments and resources in the cloud, creating new images and templates where necessary. The cloud team might still own the provisioning process—ensuring that the necessary controls, policies, and auditing are in place

SRE Makes Sense at Scale

Site Reliability Engineering is an approach to the operation and improvement of software applications pioneered by Google to deal with their global, multi-million-user systems. If adopted in full, SRE is significantly different from IT operations of the past, due to its focus on the “error budget” (namely defining what is an acceptable amount of downtime) and the ability of SRE teams to push back on poor software.

People on SRE teams need excellent coding skills and—crucially—a strong drive (and bandwidth) to automate repetitive Ops tasks using code, thereby continually reducing toil.

The SRE model sets up a healthy and productive interaction between the development and SRE teams by using service-level objectives (SLOs) and error budgets to balance the speed of new features with whatever work is needed to make the software reliable.

SRE teams are not essential; they are optional.

The relationship between an SRE team and an application-development team changes at different points of the software’s life and even month by month

Initially, the application development team alone builds and runs the software in production until the scale merits SRE help. During a second stage as the application usage increases, SRE provides guidance (represented in green) to the application development team on how to make the application work better at global scale. Later, SRE becomes fully involved by running and supporting the application (but still collaborating with the application team) when the scale merits it At this point, the product owner for the application must decide a suitable service-level objective with a corresponding error budget. If at some point the application becomes too difficult to support due to lack of operability, or if the application usage drops off, the application team takes on operational responsibility again.

that building and running software systems is a sociotechnical activity, not an assembly line in a factory.

Considerations When Choosing a Topology

1. Technical and Cultural Maturity
2. Organization Size, Software Scale, and Engineering Maturity -> Low maturity organizations will need time to acquire the engineering and product development capabilities required for autonomous end-to-end teams. Meanwhile, more specialized teams (development, operations, security, and others) are an acceptable trade- off, as long as they collaborate closely to minimize wait times and quickly address issues.

3.Splitting Responsibilities to Break Down Silos

Sometimes we can remove or lessen dependencies on specific teams by breaking down their set of responsibilities and empowering other teams to take some of them on. For example, a pattern increasingly adopted in many organizations over the past few years has been to separate the activities of database development (DB Dev) from database administration (DBA).

4.Dependencies and Wait Times between Teams Spotify relies on a simple spreadsheet to detect and track interdependencies between squads and tribes. It highlights whether a dependency is on a squad within the same tribe (acceptable) or in a different tribe (potentially a warning that team design or work assignment is wrong).

Chapter 1 - A Pragmatic Philosophy

Who are Pragmatic programers Has attitude, a style,a philosophy of approaching problems and their solutions. They think beyond the immediate problem, place it in larger context and seeking out the bigger picture. They make intelligent compromises and informed decisions and most importantly take responsibility of everything they do.

1 . You have agency

Software development appear close to the top of any list of careers where you have control. Our skills are in demand, our knowledge crosses geographic boundaries, we can work remotely. Trick is to ask for anything you want from organization and always remember “you can change your organization or change your organization.” You’re investing in yourself, so doing it while you’re off-the-clock is only reasonable.

2. The Cat Ate My Source Code

Team trust - your team needs to be able to trust and rely on you, in a healty team environment you can speak up your mind. Responsibility - when you accept the responsibility for an outcome, you should expect to be held accountable for it. When you make a mistake (as we all do ) try to offer solutions then blame. Provide Options, Don’t Make Lame Excuses Before you approach anyone to tell them why something can’t be done, is late, or is broken, stop and listen to yourself. Talk to the rubber duck on your monitor, or the cat. Does your excuse sound reasonable, or stupid? How’s it going to sound to your boss? Run through the conversation in your mind. What is the other person likely to say? Sometimes, you just know what they are going to say, so save them the trouble.

3. Software Entropy - means amount of disorder in any system. Software rot or tech debt.

A broken window Analogy One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short span of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.

Don’t Live with Broken Windows Don’t leave “broken windows’’ (bad designs, wrong decisions, or poor code) unrepaired. Comment, fix the broken window or comment to suggest the improvements and come back to it. But don’t leave broken windows.

A fire fighter analagy : The house was immaculate, loaded with priceless antiques The fire department rushed in to save burning house one day. But before they dragged their big, dirty hoses into the house, they stopped—with the fire raging—to roll out a mat between the front door and the source of the fire. They didn’t want to mess up the carpet. Now that sounds pretty extreme. Surely the fire department’s first priority is to put out the fire. But they clearly had assessed the situation, were confident of their ability to manage the fire, and were careful not to inflict unnecessary damage to the property. That’s the way it must be with software: don’t cause collateral damage just because there’s a crisis of some sort.

If you find yourself working on a project with quite a few broken windows, it’s all too easy to slip into the mindset of “All the rest of this code is crap. By the same token, if you find yourself on a project where the code is pristinely beautiful—cleanly written, well designed, and elegant—you will likely take extra special care not to mess it up, just like the firefighters. Even if there’s a fire raging (deadline, release date, trade show demo, etc.),you don’t want to be the first one to make a mess and inflict additional damage.

4. Stone soup and boiled frog

Be a Catalyst for Change

You may be in a situation where you know exactly what needs doing and how to do it. The entire system just appears before your eyes—you know it’s right. But ask permission to tackle the whole thing and you’ll be met with delays and blank stares. People will form committees, budgets will need approval, and things will get complicated. Everyone will guard their own resources. Sometimes this is called “start-up fatigue.’ It’s time to bring out the stones. Work out what you can reasonably ask for. Develop it well. Once you’ve got it, show people, and let them marvel. Then say “of course, it would be better if we added…’’ Pretend it’s not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success.

5. Good-Enough Software

Bug-free software is a myth. Time, technology, and temperament all conspire against us. Make good enough for your users, for future maintainers, for your own peace of mind. You’ll find that you are more productive and your users are happier. Involve Your Users in the Trade-Off

Make Quality a Requirements Issue - As a user, would you rather (1) wait for them to get all the bugs out, (2) have complex software and accept some bugs, or (3) opt for simpler software with fewer defects?

6. Your Knowledge Portfolio

• Invest Regularly in Your Knowledge Portfolio

The early bird might get the worm, but what happens to the early worm? Your knowledge and experience are your most important day-to-day professional assets. Unfortunately, they’re expiring assets.7 Your knowledge becomes out of date as new techniques, languages, and environments are developed

1. Serious investors invest regularly—as a habit.
2. Diversification is the key to long-term success. (different domains, disciplines )
3. Smart investors balance their portfolios between conservative and highrisk, high-reward investments. (new languages framework )
4. Investors try to buy low and sell high for maximum return.
5. Portfolios should be reviewed and rebalanced periodically.

** This can be learned. The trick is to make yourself do it initially and form a habit. Develop a routine which you follow until your brain internalizes it. At that point, you’ll find yourself sucking up new knowledge automatically **

When learning Critically Analyze What You Read and Hear trick: ask “why?” at least five times. Ask a question, and get an answer. Dig deeper by asking “why?”

7. Communicate!

Having the best ideas, the finest code, or the most pragmatic thinking is ultimately sterile unless you can communicate with other people. A good idea is an orphan without effective communication A large part of our day is spent communicating, so we need to do it well

Continuously improve your knowledge of your audience as you communicate.Plan what you want to say. Write an outline. Then ask yourself, “Does this communicate what I want to express to my audience in a way that works.

Make your style of communication and for make it look good (Your company may already have defined style sheets that you can use.). Communicate well and listen well, when you don’t know Get back to people.

When writing that Pull request description or a slack message or email. Proofread, check for spelling mistakes. omit un-necessary words. Make is clear and short. User code snippets to explain where necessary

Chapter 2 - A Pragmatic Approach

8. The Essence of Good Design

Good design is easier to change .ETC.every design principle out there is a special case of ETC. Decoupling? Because by isolating concerns we make each easier to change. ETC. Single responsibility ? Because a change in requirements should not affect other un-related modules. ETC. Why is naming important? Because good names make code easier to read, and you have to read it to change it. ETC!

How to train yourself for ETC. It requires some initial conscious reinforcement. Spend a week or so deliberately asking yourself “did the thing I just did make the overall system easier or harder to change?” It’s really just thinking about keeping code decoupled and cohesive.

9. DRY (Don’t repeat yourself) - The Evils of Duplication

Code is ever changing, requirements change , client change, industry and government regulations change.

Most people assume that maintenance begins when an application is released, that maintenance means fixing bugs and enhancing features. This is wrong. Programmers are constantly in maintenance mode. Our understanding changes day by day. New requirements arrive and existing requirements evolve as we’re heads-down on the project. Perhaps the environment changes. Whatever the reason, maintenance is not a discrete activity, but a routine part of the entire development process.

…..

10. Orthogonality

11. Reversibility

Requirements,users, and hardware change faster than we can get the software developed Most of the time, calls to third-party products are entangled throughout the code. But we really abstracted the idea of a database out—to the point where it simply provides persistence as a service—then you have the flexibility to change horses in midstream

Flexible Architecture -> What you can do is make it easy to change. Hide third-party APIs behind your own abstraction layers. Break your code into components: even if you end up deploying them on a single massive server, this approach is a lot easier than taking a monolithic application and splitting it.

But think of code evolution along the same lines as a box full of Schrödinger’s cats: every decision results in a different version of the future. How many possible futures can your code support? Which ones are more likely? How hard will it be to support them when the time comes? Dare you open the box?

12. Tracer Bullets

Particularly when you’re building something that hasn’t been built before. We use the term tracer bullet development to visually illustrate the need for immediate feedback under actual conditions with a moving goal

Tracer bullets work because they operate in the same environment and under the same constraints as the real bullets. They get to the target fast, so the gunner gets immediate feedback. They’re a relatively cheap solution.

Tracer code is not disposable: you write it for keeps. It contains all the error checking, structuring, documentation, and self-checking that any piece of production code has. It simply is not fully functional. However, once you have achieved an end-to-end connection among the components of your system, you can check how close to the target you are, adjusting if necessary. Once you’re on target, adding functionality is easy. Tracer development is consistent with the idea that a project is never finished: there will always be changes required and functions to add. It is an incremental approach. The tracer code approach has many advantages

1. Users get to see something working early
2. Developers build a structure to work in
3. You have an integration platform
4. You have something to demonstrate
5. You have a better feel for progress

Tracer Code versus Prototyping

Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired.

13. Prototypes and Post-it Notes

We tend to think of prototypes as code-based, but they don’t always have to be. Like the car makers, we can build prototypes out of different materials. Post-it notes are great for prototyping dynamic things such as workflow and application logic.

But if you find yourself in an environment where you cannot give up the details, then you need to ask yourself if you are really building a prototype at all. Perhaps a tracer bullet style of development would be more appropriate in this case

Anything you aren’t comfortable with. You can prototype: • Architecture • New functionality in an existing system • Structure or contents of external data • Third-party tools or components • Performance issues • User interface design

Prototyping is a learning experience. Its value lies not in the code produced, but in the lessons learned. That’s really the point of prototyping.

How to Use Prototypes When building a prototype, what details can you ignore?

1. Correctness - fake data
2. Robustness - Edge/error cases not covered
3. Style - may skip the guidelines, process etc

Prototypes gloss over details, and focus in on specific aspects of the system being considere.

How Not to Use Prototypes

Code-based prototyping, make sure that everyone understands that you are writing disposable code. Prototypes can be deceptively attractive to people who don’t know that they are just prototypes. You must make it very clear that this code is disposable, incomplete, and unable to be completed.

14. Domain Language

So when you force a business person to sign off on a requirements document, or get them to agree to a set of Cucumber features, you’re doing the equivalent of getting them to check the spelling in an essay written in Sumerian. They’ll make some random changes to save face and sign it off to get you out of their office. Give them code that runs, however, and they can play with it. That’s where their real needs will surface.

Document using Test Rspec, cucumber, ansible or YAML.

15. Estimating

To some extent, all answers are estimates. It’s just that some are more accurate than others. So the first question you have to ask yourself when someone asks you for an estimate is the context in which your answer will be taken. Do they need high accuracy, or are they looking for a ballpark figure?

1. Understand What’s Being Asked
2. Break the Model into Components
3. Give Each Parameter a Value
4. Keep Track of Your Estimating Prowess
5. Check requirements
6. Analyze risk (and prioritize riskiest items earlier)
7. Design, implement, integrate
8. Validate with the users

Based on that experience, you can refine your initial guess on the number of iterations and what can be included in each.T he refinement gets better and better each time, and confidence in the schedule grows along with it. This kind of estimating is often done during the team’s review at the end of each iterative cycle.

This may not be popular with management, who typically want a single, hardand- fast number before the project even starts. You’ll have to help them understand that the team, their productivity, and the environment will determine the schedule. By formalizing this, and refining the schedule as part of each iteration, you’ll be giving them the most accurate scheduling estimates you can.

What to Say When Asked for an Estimate

You say “I’ll get back to you.” You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section.

The basic tools

Plain text

Keep knowledge in plain text. HTML, JSON, YAML,and so on are all plain text. All fundamental protocols on the net, such as HTTP, SMTP, IMAP, are all plain text.

• Insurance against obsolescence • Leverage existing tools • Easier testing

Shell games

For a programmer manipulating files of text, that workbench is the command shell. Shell, you can launch applications, debuggers, browsers, editors, and utilities. You can search for files, query the status of the system,and filter output. And by programming the shell, you can build complex macro commands for activities you perform often

A benefit of GUIs is WYSIWYG—what you see is what you get. The disadvantage is WYSIAYG—what you see is all you get

Use the Power of Command Shells Gain familiarity with the shell, and you’ll find your productivity soaring. Color theme, alias, command completion, macros to do repetitive tasks

Power Editing

use as many editors as you want. We’d just like you to be working toward fluency in each.

Achieve Editor Fluency

• When editing text, move and make selections by character, word, line, and paragraph. • When editing code, move by various syntactic units (matching delimiters, functions, modules, …). • Re-indent code following changes. • Comment and uncomment blocks of code with a single command. • Undo and redo changes. • Split the editor window into multiple panels, and navigate between them. • Navigate to a particular line number. • Sort selected lines. • Search for both strings and regular expressions, and repeat previous searches. • Temporarily create multiple cursors based on a selection or on a pattern match, and edit the text at each in parallel. • Display compilation errors in the current project. • Run the current project’s tests

Version Control

Tip 28 Always Use Version Control and use it for everything. documentation, phone number lists, memos to vendors, makefiles, build and release procedures, that little shell script that tidies up log files—everything

Use it when you just want to show a title, up to three buttons, a list of selectable items, or a custom layout.

Also DatePickerDialog and TimePickerDialog are available with a pre-defined android style widgets, that allows the user to select a date or time.

DialogFragment

Use a DialogFragment as a container for your dialog, when you need

• to ensures that it correctly handles lifecycle events such as when the user presses the back button or rotates the screen.
• to allow reuse the dialog’s UI just like in a traditional Fragment (such as when you want the dialog UI to appear differently on large and small screens).

class FireMissilesDialogFragment : DialogFragment() {

    override fun onCreateDialog(savedInstanceState: Bundle): Dialog {
        return requireActivity()?.let {
            // Use the Builder class for convenient dialog construction
            val builder = AlertDialog.Builder(it)
            builder.setMessage(R.string.dialog_fire_missiles)
                    .setPositiveButton(R.string.fire,
                            DialogInterface.OnClickListener { dialog, id ->
                            })
                    .setNegativeButton(R.string.cancel,
                            DialogInterface.OnClickListener { dialog, id ->
                                // User cancelled the dialog
                            })
            // Create the AlertDialog object and return it
            builder.create()
        } ?: throw IllegalStateException("Activity cannot be null")
    }
} 

// Showing a Dialog

fun confirmFireMissiles() {
    val newFragment = FireMissilesDialogFragment()
    newFragment.show(supportFragmentManager, "missiles")
}

The show method add the fragment in transaction and commits, however you can not pop back this fragment from stack.

class CustomDialogFragment : DialogFragment() {

    /** The system calls this to get the DialogFragment's layout, regardless
    of whether it's being displayed as a dialog or an embedded fragment. */
    override fun onCreateView(
            inflater: LayoutInflater,
            container: ViewGroup?,
            savedInstanceState: Bundle?
    ): View {
        // Inflate the layout to use as dialog or embedded fragment
        return inflater.inflate(R.layout.purchase_items, container, false)
    }

    /** The system calls this only when creating the layout in a dialog. */
    override fun onCreateDialog(savedInstanceState: Bundle): Dialog {
        // The only reason you might override this method when using onCreateView() is
        // to modify any dialog characteristics. For example, the dialog includes a
        // title by default, but your custom layout might not need it. So here you can
        // remove the dialog title, but you must call the superclass to get the Dialog.
        val dialog = super.onCreateDialog(savedInstanceState)
        dialog.requestWindowFeature(Window.FEATURE_NO_TITLE)
        return dialog
    }
}

fun showDialog() {
    val fragmentManager = supportFragmentManager
    val newFragment = CustomDialogFragment()
    if (isLargeLayout) {
        // The device is using a large layout, so show the fragment as a dialog
        newFragment.show(fragmentManager, "dialog")
    } else {
        // The device is smaller, so show the fragment fullscreen
        val transaction = fragmentManager.beginTransaction()
        // For a little polish, specify a transition animation
        transaction.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_OPEN)
        // To make it fullscreen, use the 'content' root view as the container
        // for the fragment, which is always the root view for the activity
        transaction
                .add(android.R.id.content, newFragment)
                .addToBackStack(null)
                .commit()
    }
}

Changing the position of the dialog.

    private fun setupDialogProperties(alertDialog: AlertDialog) {
        val OFFSET_IN_PX = 140
        alertDialog.apply {
            window?.let { window ->
                window.setBackgroundDrawableResource(R.drawable.bg_drawable)
                window.setDimAmount(0.1f) // from 0 for no dim to 1 for full dim.
                window.attributes?.let { params ->
                    params.width = WindowManager.LayoutParams.MATCH_PARENT
                    params.height = WindowManager.LayoutParams.WRAP_CONTENT
                    params.gravity = Gravity.TOP or Gravity.CENTER
                    params.y = (OFFSET_IN_PX).toFloat())
                    params.x = 0
                }
            }
            setCanceledOnTouchOutside(true)
            setCancelable(true)
            requestWindowFeature(Window.FEATURE_NO_TITLE)
        }
    }

Notifications are a double edge sword, it can accelerate growth and engagement or could lead to immediate un-install of the app.

With each Android OS version, the notification API’s are changing and OS is increasingly becoming aware of how apps are notifying the users.

Therefore, it is important to get the notifications right in your app.

Types of notification

####Transactional: which are the notifications which are absolutely necessary

Not Transactions

Slides : Rich Android notification

Use it when you just want to show a title, up to three buttons, a list of selectable items, or a custom layout.

Also DatePickerDialog and TimePickerDialog are available with a pre-defined android style widgets, that allows the user to select a date or time.

DialogFragment

Use a DialogFragment as a container for your dialog, when you need

• to ensures that it correctly handles lifecycle events such as when the user presses the back button or rotates the screen.
• to allow reuse the dialog’s UI just like in a traditional Fragment (such as when you want the dialog UI to appear differently on large and small screens).

class FireMissilesDialogFragment : DialogFragment() {

    override fun onCreateDialog(savedInstanceState: Bundle): Dialog {
        return requireActivity()?.let {
            // Use the Builder class for convenient dialog construction
            val builder = AlertDialog.Builder(it)
            builder.setMessage(R.string.dialog_fire_missiles)
                    .setPositiveButton(R.string.fire,
                            DialogInterface.OnClickListener { dialog, id ->
                            })
                    .setNegativeButton(R.string.cancel,
                            DialogInterface.OnClickListener { dialog, id ->
                                // User cancelled the dialog
                            })
            // Create the AlertDialog object and return it
            builder.create()
        } ?: throw IllegalStateException("Activity cannot be null")
    }
} 

// Showing a Dialog

fun confirmFireMissiles() {
    val newFragment = FireMissilesDialogFragment()
    newFragment.show(supportFragmentManager, "missiles")
}

The show method add the fragment in transaction and commits, however you can not pop back this fragment from stack.

class CustomDialogFragment : DialogFragment() {

    /** The system calls this to get the DialogFragment's layout, regardless
    of whether it's being displayed as a dialog or an embedded fragment. */
    override fun onCreateView(
            inflater: LayoutInflater,
            container: ViewGroup?,
            savedInstanceState: Bundle?
    ): View {
        // Inflate the layout to use as dialog or embedded fragment
        return inflater.inflate(R.layout.purchase_items, container, false)
    }

    /** The system calls this only when creating the layout in a dialog. */
    override fun onCreateDialog(savedInstanceState: Bundle): Dialog {
        // The only reason you might override this method when using onCreateView() is
        // to modify any dialog characteristics. For example, the dialog includes a
        // title by default, but your custom layout might not need it. So here you can
        // remove the dialog title, but you must call the superclass to get the Dialog.
        val dialog = super.onCreateDialog(savedInstanceState)
        dialog.requestWindowFeature(Window.FEATURE_NO_TITLE)
        return dialog
    }
}

fun showDialog() {
    val fragmentManager = supportFragmentManager
    val newFragment = CustomDialogFragment()
    if (isLargeLayout) {
        // The device is using a large layout, so show the fragment as a dialog
        newFragment.show(fragmentManager, "dialog")
    } else {
        // The device is smaller, so show the fragment fullscreen
        val transaction = fragmentManager.beginTransaction()
        // For a little polish, specify a transition animation
        transaction.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_OPEN)
        // To make it fullscreen, use the 'content' root view as the container
        // for the fragment, which is always the root view for the activity
        transaction
                .add(android.R.id.content, newFragment)
                .addToBackStack(null)
                .commit()
    }
}

Changing the position of the dialog.

    private fun setupDialogProperties(alertDialog: AlertDialog) {
        val OFFSET_IN_PX = 140
        alertDialog.apply {
            window?.let { window ->
                window.setBackgroundDrawableResource(R.drawable.bg_drawable)
                window.setDimAmount(0.1f) // from 0 for no dim to 1 for full dim.
                window.attributes?.let { params ->
                    params.width = WindowManager.LayoutParams.MATCH_PARENT
                    params.height = WindowManager.LayoutParams.WRAP_CONTENT
                    params.gravity = Gravity.TOP or Gravity.CENTER
                    params.y = (OFFSET_IN_PX).toFloat())
                    params.x = 0
                }
            }
            setCanceledOnTouchOutside(true)
            setCancelable(true)
            requestWindowFeature(Window.FEATURE_NO_TITLE)
        }
    }

Why BroadcastReceiver.onReceive always run in the UIthread (also main thread). That means, you can not perform any long running operation.

However, in only rare cases when you need BroadcastReceiver to live longer, by using goAsync() we can tell the android framework to keep the receiver for longer approx 30 seconds.

override fun onReceive(context: Context, intent: Intent?) {

        val pendingResult = goAsync()

        Thread(Runnable {
          val id = intent?.getStringExtra(ARG_ID_KEY)
            id?.let {
                // perform long operation task
           }

            //let the system know the BroadcastReceiver can now //finish
            pendingResult.finish() 

        }).start()
    }

Other day, I was scheduling two alarms simultaneously, at some point in future, but only one was being triggerd.

When to use Alarm manger :

The Alarm Manager should be used for cases where you want to run your application code at a specific time in future, even if your application is not currently running.

In my case, I had to trigger push notification in 3 and 6 hours,after user has performed an action in the app.

When creating a pendingIntent that will perform a broadcast, we need to provide a unique request code parameter for the sender.

The problem was I was passing 0 as requestCode when creating pending intents for both alarms.

PendingIntent.getBroadcast(appContext, 0, intent, 0)

Intent(appContext, AlarmReceiver::class.java).let { intent ->
            intent.putExtra(ARG_RECIPE_ID_KEY, recipeId)
            intent.putExtra(ARG_ALARM_TYPE, alarmType.name)
            PendingIntent.getBroadcast(appContext, unique_id, intent, 0)
        }

Solution:

I created a wrapper to be injected in a class from where I needed to set an alarm.

Implementation :

Next up, perform long running IO tasks in BroadcastReceiver.onReceive

⏭️ GoAsync

Fix

Use alpha only icon.

What are alpha only icons?

Alpha only icons are transparent icons, where white acts as the visible area and black acts as the transparent area. For example, all material icons are alpha only.

Reason

Since android L onwards :

The system ignores all non-alpha channels in action icons and the main notification icon. You should assume that these icons are alpha-only.

So this exception occurs when colored image resource is used as a notification icon.

Why can’t use colored image resource ?

Device status bar backgrounds color could be of any color. There are tons of manufactures and people apply themes etc.

So Android framework only allows alpha only icons as they will be visible on any colored status bar.

 NotificationCompat.Builder(context, channelId)
 .setSmallIcon(R.drawable.ic_alpha_icon_for_notifications) //alpha only icon
 .setColor(ContextCompat.getColor(applicationContext, R.color.green)) 
 // adds your brand color over alpha icon

Happiness:

If fitness can be choice, health can be choice, nutrition can be a choice, working hard and making money can be a choice than happiness can also be a choice.

What is a desire ? A contract to make yourself un-happy and suffer, until you get what you want.

Question to ask every time you are un-happy ? What is the underline desire, I am looking to fulfil.

Don’t have too many desires and pick them unconsciously, or have thousands of them. For example, my coffee is too dark, it’s too hot here, there is a cat litter in my garden, small things will eat up your energy. Pick one overwhelming desire and suffer on that and let other let go. Save your energy for that one desire.

We live in the age of ultimate leverage, your action can be multiplied by thousand fold by:

• Broadcasting to podcast
• Investing capital
• People working for you
• By writing code

So the impact of good decision making is much higher than it’s used to be. And happy, calm and a peaceful person will make better decisions with better outcomes.

In order to stay peaceful and happy, block:

1. any outrage, stupidity on social media and in your surrounding.
2. snippets taken out of context, modified shared on news and in social media. If paid attention, they will clutter the mind.
3. The world reflects your own feeling back at you. The more you judge (annoy by little things) the more you separate from others, see negative things.
4. Watch your own thoughts, why i am having that thought does this serve me anymore, often when you understand why you have that thought, you feel calmer.

Ancient Struggle, were against other tribes, religion and food. Modern society struggles, is with yourself.

Parents, friends don’t live nearby, no tribal meaning, no religion connection. When they come to attack you : social media algorithms, video games, sugar, porn you stand alone These all are diseases of abundance, over exposure to everything, so *the way to survive is to be ascetic, retreat from society beliefs. Turn it off

Meditation :

• It is an art of doing nothing.
• Monkey mind is a disease, learn to rest your mind.
• Regrets, issues, problem, gets pilled up over time, therefore its necessary to sit down and close your eyes. Let your thoughts pass, don’t judge, don’t react and analyse.

Peace is happiness at rest

Random thoughts and Quotes

Work like lion, hunt, sprint, reset, re-access, feedback, sprint again.

Every man has 2 life , and second start when he realise he has one.

You have got one life, do many different things

What is the meaning of life?

If there was a single answer, then we will compete with each other. Answers are paradox, pointless to pursue, but the act of pursing is useful.

Do hard things in life, to make meaning of your life, and making money is fine one. *IT is NOT EASY. IT IS THE FREAKING HARDS THING YOU WILL DO * but also the most rewarding one.

Just :

• Smile more.
• Hug more.
• Go out in nature and in Sunlight.
• Happy thoughts disappear and negative linger, but you can trick your mind by looking positive aspects in every scenario.

Top three things everyone seeks :

• Wealth.
• Happiness.
• Health.

Lets talk about wealth :

We will not become rich by renting our time. We rent our time to our employer,and in return get a monthly salary. The employer, dictates how, what and where should we work. We don’t earn when we are on vacation and when we sleep.

Sure, hard work is important, but one does not simply can become wealthy by working hard, we have to work on the right thing, with the right people. A man down on a grocery store is not working any less than Elon Musk.

One can become rich by :

• Owning a piece of business.
• Having an equity as an owner or an investor.
• Becoming a share holder of a brand.
• Having leverage of people, media or code.

Lack of material possessions can make you un-happy but getting rich can not make you happy, either.

Everyone can be rich!:

• Lowering your lifestyle.
• Making enough money, far more than your burn rate.
• Lot of money saved up and the passive income from that covers your burn rate, keep your burn rate low. (ex do a remote job, live on low cost country or neighborhood hood and save money.)
• Drive your burn rate to zero …become a monk (Don’t do that if you are reading this.)
• Do something you love, you love so much it’s not about money anymore for you.
• Have specific knowledge and skill set.
  1. Be authentic, what you do.
  2. Map that to what society wants.
  3. Leverage (in form of people, money or media).
  4. Put your name on it, take the risk but you gain the rewards. High risk/ High reward situation.
• Ignore your peers, upgrading lifestyle, buying unwanted things which you don’t actually need or to impress others.
• Find the thing you know and do better than anybody else, because you love to do it. Something, for others its work, but for you its play, so no one can outnumber you, because you are authentic.

Industrial model of organizations are going to change: Boss’s, hierarchy and processes (which slows you down) We can see these days, with the advent of remote work and #digital nomads More and more people like to own their schedule, own their time and place and time where they are most productive.

In short people are favouring time and location independence.

Retirement is when you stop sacrificing today for some imaginary tomorrow.

⏭️ Happiness