Authentication and Authorization are critical issues in any IT system that deals with swnsitive informations. A distributed system as an Event-Driven collection of Microservices running on the cloud adds additional challenges for these issues.

This post recapitulates the characteristics of an Event-Driven Microservices Architecture, what is Authentication and Authorization, explains the requirements for a Solution, and finally proposes a solution that addresses these requirements.



## Microservices Architecture

All companies to survive and grow need to embrace, adapt and innovate with technologies that can improve and change their business models and operations to enable a more competitive business relationship with the market.
Digital technologies are evolving fast and having widespread adoption.
The current business scenario is been reshaped by transformations enabled by these technologies, enabling new business models and turning others obsolete.
Most of the successful startups use the Lean Startup Method, for fast discovery and implementation of new business models.

The Build, Measure, Learn Cycle is the most important model of the Lean Startup Method. It is described in the book The Lean Startup by Eric Ries from 2011. What exactly does the Build, Measure, Lean Cycle entail?

- Build - make a prototype quickly or develop another method that allows you to test your hypothesis quickly and accurately.
- Measure - measures the results.
- Learn - learn from the results. This gives you new ideas to improve your product or service.

![Build, Measure, Learn Cycle](/images/build-measure-learn-cycle-lean-startup-1.jpg)

After this, repeat these three steps (this is the Cycle). An important part of the Lean Startup Method is that the company that can repeat the above process the fastest will eventually win.

IT systems are the main tool to implement business models and operations and are an enabler of the Lean Cycle.
Microservices Architecture is the prominent software architecture that addresses the needs of current IT systems. It has the following characteristics:

- Composed by autonomous specialized services.
- Each service is intrinsically related to a business subdomain.
- Multiple technologies: each service can be implemented using the most convenient technology.

## Event-Driven Microservices

If the business model and operations are implemented by its IT systems, the IT systems should be:

- Secure,
- Available,
- Reliable
- Scalable

Event-Driven Microservices is a software architecture aimed to support availability, reliability, and scalability. It helps to deliver consistent customer experience while addressing failures and performance issues. It is based on:

- Loosed coupled services
- Intercomunication via messages

## Authentication

Identification of the user.
To check the identity of an user based on the credentials received.
The identification of an user can be composed of atributes that define roles.
The authentication can be a system service.

## Authorization

Permissions assigned for an user.
To determine if the identified user should be granted access to a particular resource.
Authorization can be specific for each service.
User relationships with domain data are determined in the service context.
Resource server.


## Requirements for a Solution

- Authentication in the first interaction in a user session
- Authentication Persistance during a user session
- Existence of a Mechanism for Authentication invalidation during a session
- Authorization based on user, context and data
- Minimal overhead in each Microservices

## A solution

- Client / Server Communication:
  - Cookies as transport mechanism
  - JWT for storing pertinent information about the user

- System Components:
  - Authentication Service
  - Authorization Service
  - Message Mechanism

- Microservice add-ons:
  - Authentication Sidecar
  - Autorization Sidecar

Data based Authentication and Authorization

JWT are access tokens
JWT enables stateless authorization

Json Web Token is a compact URL-safemeans ofrepresenting claims to be transfered between two parties. The claims are encoded as JSON object that is digitaly assigned by hashing itusing a shared secret between the parties.

A secure way to transit to encapsulate arbitary data that can be sent over unsecure URLs. Securely send a payload.
A JWT is composed of a Header, a payload (claims), and a signature.

This post explains the challenges for authentication and authorization in an Event Driven Microservices Architecture and proposes a solution.

Authentication and Authorization in a Microservices Architecture

[TypeScript](https://www.typescriptlang.org/) is an evolving type-safe superset of [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript), that offers modern language concepts and constructs.
Combined with [NodeJS](https://nodejs.org) is a favored option to write scalable applications.

A well-configured TypeScript installation can improve your _Development Experience_, _accelerating your development workflow_ and _reducing your cognitive load_.

Here, I show how I configure TypeScript, helping me work better and faster.
I explain my decisions and describe how to implement them.
You will understand my approach and have a 2021 starter TypeScript installation to use in your projects.



## Modern Applications and TypeScript

Modern Software Applications have the following features:

- are available on the internet,
- are accessed in multiples ways: browsers, smartphones, smart machines,
- are scalable, able to support changing and sometimes exponential demand,
- are mostly i/o intensive,
- are constantly evolving its functionality.

My preferred approach to enable those features is to:

- use [Agile Methodologies](https://en.wikipedia.org/wiki/Agile_software_development),
- adopt a [Microservices Architecture](https://microservices.io/patterns/microservices.html),
- deploy to public Cloud Providers (AWS, Azure, Google, etc).

TypeScript is an evolving open-sourced type-safe superset of the JavaScript language, backed by Microsoft, with the following characteristics:

- modern language concepts and constructs;
- static type checking at compiler time, preventing most of the runtime errors;
- compiles to plain JavaScript, so it runs almost anywhere;
- an ecosystem that enables a great developer experience;
- combined with NodeJS is a performant option for i/o intensive applications, like most of the modern web applications;
- all public cloud providers offer plenty of options to deploy NodeJS applications.

I write most of my software applications with TypeScript, using _Test-Driven Development_ (TDD) and building _Incremental Evolutions_ of the software.

## Installation Steps

Step by step for the installation:

1) Installation Structure.
2) TypeScript Configuration: transpile TypeScript to JavaScript.
3) Test Automation.
4) Static Code Analysis.
5) Formatting Automation.
6) Version Control.

### 1) Installation Structure

We should apply _separation of concerns_ in the structure of our project. Auxiliary files, related to installation and infrastructure should be kept separate from the files with our code.

In the root folder we should put all files that build up the installation and basic instructions:

- all configuration files;
- a README file describing the purpose of the application, how to install, run and test it.

The source code for the application should be located in a dedicated folder; I use the "src" folder.
It is convenient for our application to have a CLI to call it. This CLI gets environment parameters and calls our main function. So our main function is isolated from the external environment, it receives parameters and returns a result. This allows for easier testing and cross-target building, if necessary.

In this minimal installation, the source folder ("src") will have 3 files:

- cli.ts - the CLI entry point for the application,
- main.ts - the main function that receives parameters and returns a final result,
- main.spec.ts - the test specification for the main function.

This structure can be built with the following commands:

```bash
# Create the folder for your project
$ mkdir my-project
$ cd my-project

# Create source folder and files
$ mkdir src
$ touch src/main.ts src/main.spec.ts src/cli.ts

# Create a package.json
$ yarn init -y

# Create the typescript configuration file
# (tsconfig.json)
$ tsc --init

# Create folder for the generated javascript
$ mkdir build
```

### 2) TypeScript Configuration

Edit the tsconfig.json file and define where to transpile TypeScript to JavaScript. Add these lines before "compilerOptions" settings:

```json
  "include": ["src"],
  "exclude": ["node_modules", "build"],
```

Uncomment and define these keys under "compilerOptions":

```json
/* Generates corresponding '.map' file. */
"sourceMap": true,
/* Redirect output structure to the directory. */
"outDir": "./build",
```

Keep the keys:

```json
/* Specify ECMAScript target version */
"target": "es5",
/* Specify module code generation */
"module": "commonjs",
/* Enable all strict type-checking options. */
"strict": true,
/* Enables emit interoperability between
 CommonJS and ES Modules via creation
 of namespace objects for all imports.
 Implies 'allowSyntheticDefaultImports'. */
"esModuleInterop": true,
/* Disallow inconsistently-cased references
 to the same file. */
"forceConsistentCasingInFileNames": true
```

Installing TypeScript transpiler, NodeJS types, and ts-node to run TypeScript code files directly on NodeJS:

```bash
# Install as development dependencies
$ yarn add -D typescript @types/node ts-node
```

Edit "src/main.ts" and put this initial code:

```typescript
export const main = (): string => {
  return "Hello World!"
}
```

Edit "src/cli.ts" and put this initial code:

```typescript
import { main } from './main'

console.log(main())
```

To run the CLI entry point and to build a javascript version of the application, edit the package.json file and just after the flag setting "license": "MIT", define the "scripts" flag setting with:

```json
"scripts": {
  "build": "tsc",
  "cli": "ts-node src/cli.ts"
},
```

To run the application using the CLI entry point execute:

```bash
# Run the cli
$ yarn cli
```

It should produce the following on the console:

```bash
yarn run v1.22.5
$ ts-node src/cli.ts
Hello World!
Done in 2.00s.
```

To build a javascript version in the build folder:

```bash
# Build the application's JavaScript version
$ yarn build
```

### 3) Test Automation

There are good options for testing TypeScript. I prefer [Jest](https://jestjs.io/).
It's straightforward to write back-end tests with it.
If necessary it can be easily combined with complementary software.
For the front-end development, I use [React](https://reactjs.org/) and [NextJS](https://nextjs.org/). Jest was built by FaceBook for testing React, so it is an easy pick.

Test automation enables _Test Driven Development_ TDD.
You should write tests specifying the desired behavior of your code,
before writing the actual code.
TDD requires quick and easy testing of our code as we evolve it.
I use Jest with the watchAll option to continuously watch the source files and automatically rerun the tests after any change.

Install Jest to enable test automation:

```bash
# Install as development dependencies
$ yarn add -D jest ts-jest @types/jest
```

Create a Jest configuration file ("jest.config.json") in the root folder with this content:

```json
{
  "testEnvironment": "node",
  "preset": "ts-jest",
  "testMatch": ["<rootDir>/src/**/*.spec.ts"],
  "watchPathIgnorePatterns": [],
  "collectCoverageFrom": [
    "src/**/*.{ts,js,jsx}", "!src/cli.ts"],
  "coverageThreshold": {
    "global": {
      "branches": 100,
      "functions": 100,
      "lines": 100,
      "statements": 100
    }
  },
  "coverageReporters": ["lcov", "text"],
  "moduleDirectories": ["node_modules","src"]
}
```

This configuration file defines:

- that a test file has ".spec." in its name
- that the source code is in the "src" folder
- the test coverage parameters

To facilitate the running of tests, add to the package.json file, in the "script" flag "setting":

```json
"test": "jest --config ./jest.config.json --watchAll",
"test:coverage": "jest --config ./jest.config.json
  --coverage || open coverage/lcov-report/index.js",
```

All the commands for "test:coverage" should be in just one line.

Let's define the "test" file. Edit "src/main.spec.ts" and add this content:

```typescript
import { main } from './main'

describe('Testing Application', () => {
  it('should return Hello World!', () => {
    expect(main()).toEqual('Hello World!')
  })
})
```

Now we can develop the application fully testing it, testing a specific component, and check the test coverage. Here are the commands:

```bash
# Watch the source and execute all tests
$ yarn test

# Watch the component source and execute its tests
$ yarn test component

# Execute all tests and calculate the test coverage
$ yarn test:coverage
```

### 4) Static Code Analysis

Code quality ensures that our code won’t fail on avoidable errors.
Lint tools improve code quality by doing static analysis: checking code for readability, maintainability, and functionality errors, and also may modify the code, improving it.
They help prevent that our code break. Accidentally misspelling a variable, letting case/switch statements fall through, or other silly mistakes that will potentially break your application.

There are many preconfigured lint tools for TypeScrit. Most of them are
[ESLint](https://www.npmjs.com/package/@typescript-eslint/eslint-plugin) configurations or plugins.
Some of the most used are [unicorn](https://www.npmjs.com/package/eslint-plugin-unicorn) and [airbnb](https://github.com/airbnb/javascript).
[Here](https://project-awesome.org/dustinspecker/awesome-eslint) is a list of TypeScript lints.

I use plain [ESLint](https://www.npmjs.com/package/@typescript-eslint/eslint-plugin), that is a TypeSrcipt Lint tool that works with rules.

To install ESLint:

```bash
$ yarn add eslint @typescript-eslint/eslint-plugin \
@typescript-eslint/parser --dev
```

Create a configuration file ".eslintrc" in the root folder with this content:

```json
{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"],
  "rules": {
    "@typescript-eslint/indent": ["error", 2],
    "@typescript-eslint/no-unused-vars": "error",
    "@typescript-eslint/no-explicit-any": "error"
  },
    "parserOptions": {
      "ecmaVersion": 2021
  },
  "extends": [
      "plugin:@typescript-eslint/recommended"],
  "overrides": [
    {
      "files": ["*.js"],
      "rules": {
        "@typescript-eslint/no-var-requires": "off"
      }
    }
  ]
}
```

### 5) Formating Automation

The readability is improved if we adopt a unique format for the code.
[Prettier](https://github.com/prettier/prettier) formats the code to a common standard.
I use ESLint combined with Prettier for linting and formating.

To install prettier combined with ESLint:

```bash
$ yarn add prettier eslint-config-prettier \
eslint-plugin-prettier --dev
```

Create a configuration file ".prettierrc" in the root folder:

```bash
$ touch .prettierrc
```

To configure "ESLint" to work in conjunction with "Prettier", modify ".eslintrc":

```json
{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"],
  "rules": {
    "@typescript-eslint/indent": ["error", 2],
    "@typescript-eslint/no-unused-vars": "error",
    "@typescript-eslint/no-explicit-any": "error"
  },
    "parserOptions": {
      "ecmaVersion": 2021
  },
  "extends": [
      "plugin:@typescript-eslint/recommended",
      "plugin:prettier/recommended"
  ],
  "overrides": [
    {
      "files": ["*.js"],
      "rules": {
        "@typescript-eslint/no-var-requires": "off"
      }
    }
  ]
}
```

### 6) Version Control

Incremental Evolution is based on implementing, testing, and saving small advances in the work, as small milestones towards the desired outcome. The _walking skeleton_ model is a pattern for that.
This allows a safe evolution and an overall faster development.
It is done with TDD and the support for versioning in a repository.
I use git for versioning and [github.com](https://github.com/) to put my repositories.

This command (executed at the root folder) creates a repository:

```bash
$ git init
```

The repository should keep versions of just the files necessary to rebuild our project.
The ".gitignore" at the root folder file defines files that need not be in our repository and should be ignored. [Here](https://github.com/microsoft/TypeScript-Node-Starter/blob/master/.gitignore) is the Microsoft recommendation of it. I just change the "dist" folder for "build".

## Bonus: Simplify Import Statements

Bigger projects mean more source folders and files. Possibly other collaborators.
Presence of "unfamiliar" code. All of these increase the cognitive load to work.
To work effectively in bigger Projects, it is necessary to reduce the cognitive load,
making it easier to understand the code.

As our projects grow and the code is distributed among different folders, forming a tree, each folder corresponding to a module. To facilitate the importing of references from modules, in a way that encapsulates the implementation and location of the modules, we can use two patterns:

- ***export from the modules*** - use index.ts files inside each folder, that import all the references from the files in this folder, and export from there. External code will be able to import those references specifying as the location only the folder name, no need to know the specific file names.
- ***absolute module names*** - use abbreviated absolute names for these modules, independently of the relative positioning of the exporting and importing modules.

These patterns reduce the cognitive load and the coupling between the modules.

To enable absolute module names I use [module-alias](https://www.npmjs.com/package/module-alias).
To install it:

```bash
$ yarn add -D module-alias
```

Edit these setting flags into "tsconfig.json", inside "compilerOptions":

```json
/* Base directory to resolve non-absolute module names */
"baseUrl": "./src",
/* Entries which re-map imports relative to the 'baseUrl' */
"paths": {
  "@/*": ["*"]
}
```

To enable Jest to understand the alias add this stting flag to "jest.config.json", just after "moduleDirectories":

```json
"moduleNameMapper": {
  "@/(.*)$": "<rootDir>/src/$1"
}
```

Insert this line at the very main file of your app, before any code

```javascript
import 'module-alias/register'
```

Now to import just precede the folder name with '@'

```javascript
# instead of
import * from '../../../../some/very/deep/module'
# you can use
import * from '@module'
```

Now we have a TypeScript Starter configuration that helps us to be better developers having a better developer experience.

The repository with this installation up to here is hosted [here](https://github.com/gpazevedo/ts-starter).

Why and how to set up TypeScript to help you develop modern applications with TDD, _accelerating your development workflow_ and _reducing your cognitive load_ .

TypeScript Starter for a Better Developer Experience in 2021

High-quality software designs are easier and safer to work with. Investing in quality demands discipline and skill. _Good design principles are usually helpful. But are they always applicable?_

This post investigates the applicability of the “Open-Closed Principle” when adding new functionality to a software design whose source code is entirely under our control.

Our argument is based on [Dijkstra’s](https://www.cs.utexas.edu/~EWD/) concept of [separation of concerns](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html).



## The Open/Closed Principle (OCP)

The “[Open/Closed Principle](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)” (OCP) was first advocated by [Bertrand Meyer](https://bertrandmeyer.com/) in the first edition (1988) of his book “[Object-Oriented Software Construction](https://www.amazon.com/gp/product/0136290493)” and is considered by [Bob Martin](https://blog.cleancoder.com/) as “the most important principle of object-oriented design”.

OCP states that modules should be _open for extension and closed for modification._ New functionality should be implemented by adding new classes, attributes and methods, instead of changing the current ones.

The simplest way to apply OCP is to implement the new functionality on new derived (sub)classes that inherit the original class implementation. Another way is to mediate client access to the original class with an abstract interface, so new functionality can be implemented on new classes that are accessed through the same interface. Both ways create new classes and leave the original implementation untouched.

## Modular and Expressive Abstractions

_High-quality software designs are made of modular and expressive abstractions._

Modularity is a design quality at the syntactical level. A design’s abstraction is a module if its internal implementation and external context are coupled only through the specification of its responsibilities.

Modular designs enable abstractions to be locally implemented and globally reusable. Modularity facilitates human minds to engineer highly complex and adaptable systems.

Expressiveness is a design quality at the semantic level. A design’s abstraction is expressive if its specification represents a domain concept.

Expressive designs can easily articulate abstractions that clearly express the relevant concepts, problems and solutions. Expressiveness facilitates understanding and communication that enable human minds to engineer relevant and valid solutions.

_Identifying, representing and separating relevant concerns is the fundamental principle for our design process._

Concerns bridge syntax and semantics to define abstractions and assign responsibilities that compose and decompose modular and expressive designs.

## When OCP should be Deliberately Broken

When our domain model, system requirements or design objectives change radically, new concerns unfold and emerge as relevant.

The new concepts, problems and solutions can only be expressed after the respective concerns are also represented and separated in the design; otherwise, we would introduce duplication and break modularity.

The emerging concerns must be distilled from all the modules where they were mixed with other concerns. That is when we deliberately break the OCP, opening and changing previously existing classes in order to represent and separate the new concerns.

New relevant concerns can emerge from either small or big changes. Fowler’s Video Store didactic program provides us with a [good example](https://web.archive.org/web/20181204101941/http://blog.symprise.net/2009/01/revisiting-fowlers-video-store-01-object-oriented-syntax/). Creating an HTML version of the customer’s statement makes formatting a relevant concern. The `statement` method must be opened and factored to avoid duplication. After _formatting is separated from content,_ the OCP again must be observed when creating new versions for other formats.

Separation of concerns not only guides the deliberate breaking of the OCP but also fundamentally underlies the “[Single Responsibility Principle](https://en.wikipedia.org/wiki/Single-responsibility_principle)“.

Picture from [WikiMedia Commons](https://en.wikipedia.org/wiki/File:Edsger_Wybe_Dijkstra.jpg).

This post investigates the applicability of the Open-Closed Principle. Our argument is based on Dijkstra’s concept of separation of concerns.

Computer pioneer and genious Edsger Wybe Dijkstra

The Open/Closed Principle: Concerns about Change in Software Design

**Refactoring** techniques and **Design Patterns** have been extensively propagated and advocated for over a decade now. Why we still find it hard to change, anaemic or overly complex object-oriented structures? What is missing in our design practices?

We posit that continuously refining the abstractions we build in our code is a necessary ingredient for effective refactoring.

In this series, we use Fowler’s didactic Video Store program to show how the focus on refining abstractions generates **practical advanced refactoring strategies that improve design simplicity, expressiveness and flexibility beyond standard object-oriented practice.**



## Refactoring and Design Patterns

Refactoring is a modularity improving technique that is essential for any evolutionary software development process and indispensable in the skill set of any professional software developer.

In the extremely influential book [“Refactoring: Improving the Design of Existing Code”](https://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672), Martin Fowler defines Refactoring as “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behaviour”.

Fowler’s Refactoring book and the [GoF Design Patterns book](https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612) have played a fundamental transformational role in the professional community, educating a generation of software developers on their move from the procedural to the object-oriented design paradigm. More recently, Joshua Kerievsky published [Refactoring to Patterns](https://www.amazon.com/Refactoring-Patterns-Joshua-Kerievsky/dp/0321213351), leading refactoring to a new level of abstraction by explicitly combining both approaches.

Despite all these resources, why we still see complex object-oriented structures, contrary to the objectives of simplicity, expressiveness and flexibility, also implied by the refactoring definition?

## What is Missing?

_High-quality software designs are made of modular and expressive abstractions._

>> “If developers don’t realise that changing code changes the model, then their refactoring will weaken the model rather than strengthen it.”

[Domain-Driven Design](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software-dp-0321125215/dp/0321125215), by Eric Evans

Refactoring and design patterns are misused by a large number of software developers. There is an excessive focus at the syntactical level. A broader and deeper perspective is needed when analysing modularity problems and directing the refactoring process towards greater relevance to its design objectives.

The missing points are:

1. each refactoring step is an **opportunity for refining abstractions**;
2. abstraction refinements should **improve both modularity and expressiveness**.

In summary: refactoring processes should consider the program’s context and domain semantics to explicitly rethink both its design structure and abstractions at each refactoring step.

## Refining Abstractions

Effective refactoring transcends the program’s text and syntax to improve modularity and keenly enhance simplicity, expressiveness and flexibility.

Fowler’s book introduces refactoring techniques with a small program for a video store, whose main function is to print a statement of a customer’s charges and their frequent renter points.

In this series, we use Fowler’s very simple and rich didactic example to illustrate the following refactoring strategies:

1. **Adopt Object-Oriented Modules.** Apply a proper object-oriented design to reduce syntactical noise and make programs easier and safer to work with. Prepare your program to implement most new requirements by small and focused interventions, without generating unintended side effects.

2. **Reveal the Relevant Domain Concepts.** Listen carefully to the domain experts to reduce semantic noise by making their relevant concepts explicit and evident in all design expressions.

3. **Align with Contextual Variance.** Confront program invariants with contextual variances to help make design decisions that improve both consistency and flexibility.

These refactoring strategies have been consistently beneficial to our software design practice over the years. In case you haven’t yet, we strongly suggest you try them in your daily software development activities. We will be very happy to listen to your feedback with ideas and experience with software design and refactoring.

The source code for this software design exploration can be found [here](https://github.com/RPAzevedo/Sympriser-VideoStore).

Revisiting Fowler’s Video Store: Refactoring Code, Refining Abstractions

_“Experienced project managers can deal more effectively with complex software projects”. Really?_



This “conventional truth” is contradicted by INSEAD professors [Sengupta](https://scholar.google.com/citations?user=odTsd5oAAAAJ) and [Van Wassenhove](https://scholar.google.com/citations?user=m1j2OiwAAAAJ)‘s research on experience-based learning.

They tested the skills of hundreds of professional project managers using a computer-assisted game, built from professor [Abdel-Hamid](http://www.amazon.com/Software-Project-Dynamics-Integrated-Prentice-Hall/dp/0138220409)‘s renown _simulation models for software development._ The game was configured to represent a complex environment and most participants confirmed it replicated real-world project situations.

Some of the research results and conclusions are reported in the article [“The Experience Trap“](https://hbr.org/2008/02/the-experience-trap), published in the February 2008 edition of HBR magazine:

- experienced managers don't outperform less experienced ones;
- replaying the game didn't improve their performance;
- most managers believe project size underestimation and consequent quality, timing and cost problems are recurring flaws in complex projects.

According to the authors, many experienced managers are **trapped by their rigid mental models** to repeat intuitive and successful behaviours they learned in earlier and simpler projects. The same behaviours can be ineffective or even counter-productive in more dynamic and complex environments.

Research on project management effectiveness is relevant to both individuals, organisations and institutions. Leaders in the professional community, like SAP’s [Paul Ritchie](https://www.linkedin.com/in/paulritchie/), have been [highlighting and reflecting on the article main points](http://crossderry.wordpress.com/?s=the+experience+trap).

I agree with the colleagues that don’t accept high failure rates nor unsurpassable barriers to continuous learning and professional evolution.

Changes are, of course, necessary at both institutional and individual level. We will address these changes examining the aspects of our professional practice that are most relevant for acquiring proficiency from our experience as project managers:

- **How we think.** Does our thinking style enables or constrains our perception and learning capabilities?
- **How we learn.** Do we consciously and actively pursue learning and building knowledge from experience?
- **How we lead.** What are our focus and purpose for leadership?

Let’s explore these topics on the next posts on Project Management Effectiveness.

_The original version of this article was published at [Better Projects](http://www.betterprojects.net/2008/05/pm-effectiveness-experience-trap.html)._

PM Effectiveness – The Experience Trap

Software Design, Technical Leadership and Business Innovation

The Sympriser Blog

Welcome!

Top Articles

Authentication and Authorization in a Microservices Architecture

TypeScript Starter for a Better Developer Experience in 2021

The Open/Closed Principle: Concerns about Change in Software Design

Revisiting Fowler’s Video Store: Refactoring Code, Refining Abstractions

PM Effectiveness – The Experience Trap