I’m recognizing more and more principles. I think of principles as patterns of patterns. Principle: Refactoring With refactoring, I mean as mentioned in [[model-3-axes-of-software-development.md|Model_ 3 Axes of software development]] Keeping functionality stable Keeping performance open Optimize for development (readability / adaptiveness /…) Sometimes this is to better communicate what the code is doing. Sometimes this is to prepare for a functionality change. Last year, I realized during a postmortem, that this technique ‘refactoring’ can also be applied on an architecture level. [[opinion-better-process-to-extract-a-service-from-big-ball-of-mud.md|Opinion_ better process to extract a service from big-ball-of-mud]] And recently, I’ve been thinking that perhaps a similar approach is possible for an organisation that wants to restructure departments and teams. [[opinion-we-should-stop-big-bang-company-restructuring.md|Opinion_ we should stop ‘big bang’ company restructuring]] zooming patterns refactor Code Library Architecture scale up vs scale out Applications Teams in org Service boundaries [[model-service-boundaries.md|Model_ Service Boundaries]] Model: coherent code (package, class, method) Model: value stream boundaries Wip limit (Kanban) Story - only work on one at a time as a team OKRs (what if an entire department only has one?) Products (active development or phase out) cf “opinion: freeze projects causes hidden rewrites” Lean / ‘implement as little as possible’ [[technique-constrain-with-error-messages-to-slice-stories.md|Technique_ constrain with error messages to slice stories]] Slicing stories = constraints = error states Prioritizing stories / features Story/feature level: add as many constraints (aka error states) as possible Product level: do you really need this feature? [[pattern-split-what-and-how-when-naming.md|Pattern_ Split what and how when naming]] what: point of view = “user” object how: point of view = implementation zoom function name vs implementation interface name vs implementation class name Choreography vs orchestration Architecture [[architecture-the-hard-parts-workflow-choreography-vs-orchestration.md|Architecture_ The Hard Parts - workflow choreography vs orchestration]] Code design will I have a chain, or have one method that calls everything one by one Will I use an event bus TDD Inside out Outside in Acceptance Criteria in Story refinement ? Metrics (production data) on feature/experiment/epic level ? OKR on initiative level (lean value tree?) Slice stories with constraints. + TDD all the error states + only allow the simplest (useless) case