Published

something that has happened in the past that is relevant to the business (src’s src: from summary book Eric Evans (not the blue book) ) (src: Video_ Design Heuristics - Mathias Verraes - KanDDDinsky 2018)

(src: https://www.youtube.com/watch?v=9ZgSz6xAfL8) Model_ Clue Bucket (aka toolbox) Model_ Patterns vs Principles vs Heuristics Model_ distill your heuristics Model_ competing heuristics Heuristic: things that change together should stay together named: Single Responsibility Model_ Method for deliberate design choices Exercise Model_ Domain Event Exercise: Which attributes should be in this domain event? who placed it when was it placed Heuristic: when did something happen, is that relevant? Heuristic: what are all the timestamps that matter when it happened when we learned about it when we recorded it pre-dated who cares about this?...

Model: how beliefs are formed Hear Believe (check) Hearing is believing Hearing is confirming Fake news does not change beliefs, but it confirms/entrenches already existing beliefs (src: Book_ thinking in Bets - Annie Duke)

decision quality != decision outcome resulting happens when you mix those two Is driving a good or bad decision? You’re drunk, you drive, you have an accident -> bad You’re drunk, you drive, you get home safely -> good You’re sober, you drive, you have an accident -> bad You’re sober, you drive, you get home safely -> good If you answered bad / good as above, you were resulting. You conflated decision outcome with decision quality...

Model: 3x for estimates “No estimates” idea is great or bad depending on which phase you’re in explore: estimates are waste -> great idea in exploration, because you’ve never done it before -> estimate is just a guess, no value, wasted effor expand: (not mentioned in talk) extraction: -> estimates are important data for making decisions -> do I do project A or project B -> estimates are useful input for ROI...

(src: Course_ ADSD - Fallacies of Distributed Computing) role: Business Analist role: Architect role: Project Manager Estimates Given a - well-formed team (worked together) - with required skills (has done such things before) - of size S I like how estimates formulated this way, drive Proof-of-Concepts with the sole focus of getting better estimates. This then lowers risk & variability by shifting that to the beginning of the project....

Lens: Estimates Focusing - not possible Delivering - possible / easy Optimising - not valuable At Focusing (zone 1) there is not enough stability in the system to make estimates. Hidden technical debt can pop up when working, delaying otherwise simple things. At Delivering (zone 2) there is wel maintained code. Little or no hidden bugs or nasty surprises. Previous work is representative of future. So it’s possible to do pretty accurate estimations....

Lens: Team Composition (1) Focusing developers testers operations security business expert business decision (2) Delivering developers testers operations security business expert business decision (3) Optimizing developers testers operations security business expert business decision (src: Model_ Agile Fluency)

Earlier, I got my service app working with pasting my public key manually in the UI. And `POST https://{{OKTA_DOMAIN_AUTH}}/oauth2/v1/token` gave me a bearer token. While changing my flow to use a URL for my keys. I pasted the URL in the admin UI But `POST https://{{OKTA_DOMAIN_AUTH}}/oauth2/v1/token` now returns the error { "error": "invalid_client", "error_description": "Error retrieving the client JWKSet from jwks_uri." } solution: make sure your headers return content-type: application/json that made the error go away....

Model_ resulting - decision quality vs decision outcome Learn what 20% or 30% chance of failure actually is like. Reminds me of investing advice from option traders: “whatever you do, make sure that you can still continue the next day” - Nassim Taleb’s books Model_ how beliefs are formed