Project-Management on Osmar Petry

Backend Architectures — history, case studies & dogfooding

Mon, 01 Sep 2025 00:00:00 +0000

Summary

Know the history (monolith → services → serverless) to choose the right shape for now.
Use dogfooding to turn internal capabilities into platforms and eventually products.
Pair tech + finance on every decision so architecture choices have a clear P&L story.

Case studies (what they did → why it mattered)

Amazon: built infra & tooling for itself first (dogfood) → later externalized as AWS (new revenue, 2× monetization of the same effort).
Netflix: hybrid of microservices + serverless; serverless for bursty/edge workloads, services for core domains → speed + cost control.
Google: evolved from large coordinated monoliths to microservices as scale/teams grew → independent deploys and targeted reliability.
Uber: reused profile, payments, geo, notifications to launch Eats quickly → time-to-market by reusing platform primitives.

Decision heuristics (when to pick what)

Monolith first when the team is small, domain still moving, and you need velocity.
Split by domain (bounded contexts) when teams block each other and deploys become risky.
Serverless for event-driven, spiky, or edge tasks where operational burden must be minimal.
Always design for observability (logs/metrics/traces) and clear failure domains.

Dogfooding → productization loop

Build the capability you need (internal API/service).
Harden with SLOs, docs, dashboards.
Reuse across 2–3 internal products (prove generality).
Abstract contracts (versioning, quotas, cost model).
Externalize (SDKs, billing, support) when economics are clear.

Two-sided payoff: internal reuse lowers cost/time, externalization creates revenue.

Conway’s Law — origins, literature, and team design

Tue, 15 Apr 2025 00:00:00 +0000

Reference stack

Melvin Conway, “How Do Committees Invent?” (1968).
Thoughtworks, “Applying Conway’s Law to Improve Your Software Development.”
M. Soldani et al., “A Decade of Conway’s Law: A Literature Review 2003–2012” (IEEE).
Video summary: https://youtu.be/SWrlFod8t5g.

Essence of the law

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”

Architecture mirrors team communication pathways; siloed teams create siloed modules, joined at fragile seams.
“Monolithic teams do not build microservices”—system modularity depends on cross-team autonomy and shared vocabulary.
Neglecting communication design results in accidental system design, rather than deliberate architecture.

Historical context & popularization

Conway observed the phenomenon across software, military, and governmental projects in the 1960s.
Frederick Brooks amplified the idea in The Mythical Man-Month, cementing “Conway’s Law” in software folklore.
Later research confirms that org charts and interface diagrams often align, sometimes unintentionally.

Key takeaways from the literature review

Larger organizations introduce communication friction, leading to complex, tightly coupled systems.
Parkinson’s Law: management layers tend to expand, exacerbating coordination overhead.
Small, autonomous teams (“two-pizza teams”) correlate with cleaner, more modular architecture.

Review questions

How does organizational structure influence the resulting system design?

Systems reflect the communication patterns of their creators; poor cross-team collaboration manifests as brittle interfaces.

How does company size impact system complexity?

As organizations grow, coordination paths lengthen, producing sprawling systems with integration pain; keeping teams small mitigates the effect.

Practical implications

Design teams around the architecture you want (the “inverse Conway maneuver”): align squads to bounded contexts before writing code.
Optimize for communication density: co-locate domains, create shared rituals, and collapse unnecessary hierarchy.
When introducing API gateways or platform teams, ensure their communication network matches the required integrations.
Regularly map org structures to architecture diagrams; adjust teams when misalignment appears.

Next actions

Compare current team topology with service/module boundaries; plan reorg if misalignment exists.
Share the original essay and Thoughtworks article with engineering leadership to ground discussions in historical context.
Incorporate Conway’s Law checkpoints into architecture reviews (e.g., “Does a team own each interface?”).

[[DbC|Design by Contract]]
[[no-silver-bullet-1986|No Silver Bullet — Essence & Accidents]]
[[parnas-modularization-1972|Modularization Criteria — Parnas 1972]]
[[software-aging-1994|Software Aging]]

Decision-Making Traits of Great Software Engineers

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

Based on 59 interviews with senior Microsoft engineers (Meyer, Zimmermann, Fritz, ICSE 2015). Identifies 53 characteristics grouped into personal qualities, decision-making, team impact, and product impact. Focus here is on decision-making skills that differentiate top engineers.

Key points

Deep knowledge of organisational context (people, priorities, constraints).
Ability to switch between big-picture vision and low-level details.
Balancing short-term deliverables with long-term maintainability.
Evaluating risks and trade-offs before committing to technical choices.
Creating shared context: ensuring stakeholders understand constraints.
Fostering psychological safety so teammates surface concerns early.
Anticipating future needs; keeping options open for future change.
Honesty and transparency in communicating limitations or unknowns.

Connections

Aligns with soft-skill emphasis: empathy, collaboration, cultural awareness.
Supports literature on leadership, team coordination, and human factors in project success.
Critiques traditional curricula (ACM/IEEE) for insufficient real-world detail.

Questions

How to cultivate these 53 traits under tight deadlines?
Which traits matter most in startups vs large enterprises?
How to measure and reward decision-making soft skills in performance reviews?
How much does organisational context enable or limit development of these traits?

Personal reflections

Excellence extends beyond technical mastery; requires self-development, empathy, systems thinking, and collaboration.
Leaders must build psychologically safe environments to encourage healthy decision-making.
Curriculum reform should focus on practical, context-aware training.
Use findings to guide career development and performance evaluation discussions.

References

Meyer, A. N., Zimmermann, T., & Fritz, T. (2015). What Makes a Great Software Engineer? ICSE Proceedings. https://www.researchgate.net/…/What-Makes-a-Great-Software-Engineer.pdf

Design by Contract (DbC)

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

Bertrand Meyer introduced Design by Contract (DbC) to formalise expectations between software components. Contracts specify obligations and benefits for clients and suppliers via preconditions, postconditions, and invariants, enabling safer, more maintainable systems.

Key points

Contracts: Define preconditions (caller responsibilities), postconditions (supplier guarantees), invariants (state consistency).
Runtime checks: Contracts can be enforced during development/testing to catch violations early.
Documentation: Contracts serve as precise specs and executable documentation.
Encapsulation: Components hide implementation details while exposing contractual behaviour.
Reuse & reliability: DbC encourages reusable components with clear expectations.

Connections

Basis for Eiffel language features; influences modern assertion frameworks.
Complements unit testing and TDD by clarifying expected behaviour.
Aligns with API design best practices and microservice contracts.

Questions

How to balance DbC runtime checks with performance constraints?
How to integrate DbC in languages without native support?
When should contracts be relaxed or extended as systems evolve?

Personal reflections

Contracts clarify team communication and reduce misunderstandings.
Useful for critical systems where correctness outweighs overhead.
Combining DbC with automated tests and CI improves confidence in deployments.

References

Meyer, B. (1992). Applying “Design by Contract”. Computer, 25(10), 40-51.
Official Eiffel documentation on DbC.

[[conways-law-birth-1968|Conway’s Law — origins, literature, and team design]]
[[design-patterns|Design Pattern]]
[[ddd|Domain-Driven Design: Tackling Complexity in the Heart of Software]]
[[no-silver-bullet-1986|No Silver Bullet — Essence & Accidents]]
[[parnas-modularization-1972|Modularization Criteria — Parnas 1972]]
[[shape-up-2020|Shape Up: Stop Running in Circles and Ship Work that Matters]]
[[software-aging-1994|Software Aging]]

No Silver Bullet — Essence & Accidents

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

Frederick P. Brooks Jr. (1986) argues there’s no single “silver bullet” that will provide an order-of-magnitude productivity boost in software engineering. Distinguishes essential difficulties (intrinsic to software) from accidental difficulties (tooling, implementation). Technological advances continue to chip away at accidental issues, but inherent complexity remains.

Key points

Essence vs accidents
Essential: inherent complexity, changing requirements, invisibility, costly change.
Accidental: tooling limitations (manual compilation, lack of IDEs) that technology can mitigate.
Central thesis: innovations (OO, AI, higher-level languages) alone won’t deliver 10x productivity across the board.
Potential breakthroughs: rapid prototyping, incremental development, empowering great designers.
Critique of techno-optimism: automating accidental tasks doesn’t fix mis-specified requirements or poor communication.

Connections

Relates to discussions on technical debt (unmanaged accidental complexity).
Anticipates agile principles (short iterations, prototyping).
Aligns with critiques of low-code/no-code as silver bullets.
Connects to cognitive complexity in distributed systems.

Questions

Where do modern frameworks (React, Kubernetes) fall in essence vs accidents?
Does generative AI (Copilot) confirm or challenge Brooks’ predictions?
Has cloud computing reduced essential complexity or just moved it around?
Do DORA metrics (deployment frequency, etc.) mostly track accidental difficulties?

Personal reflections

Essential/accidental distinction explains why microservices fix operational issues but add systemic complexity.
Emphasising “great designers” foreshadows Site Reliability Engineering and other multiplier roles.
Invisibility still critical in distributed architectures; justifies heavy investment in observability.
Incremental evolution (“UNIX philosophy”) continues to beat grand revolutions.

Detailed notes

Essential difficulties: complexity, conformity, invisibility, cost of change.
Accidental wins: high-level languages, IDEs, CI/CD automation.
Suggested strategies: buy vs build, rapid prototyping, nurture expert designers.
Predictions validated: OOP aided encapsulation but didn’t eliminate logic bugs; open source helped with accidental costs, not conflicting requirements.
Quote: “Complexity is the soul of software; there is no silver bullet.”

References

Brooks, F. P. Jr. (1986). No Silver Bullet: Essence and Accidents of Software Engineering. (Link: http://www.cs.unc.edu/techreports/86-020.pdf)
Additional commentary and analyses (ACM DL, Wikipedia, etc.).

[[conways-law-birth-1968|Conway’s Law — origins, literature, and team design]]
[[DbC|Design by Contract]]
[[parnas-modularization-1972|Modularization Criteria — Parnas 1972]]
[[shape-up-2020|Shape Up: Stop Running in Circles and Ship Work that Matters]]
[[software-aging-1994|Software Aging]]

Software Aging

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

David L. Parnas likens software aging to biological aging: over time, software becomes harder to maintain, less efficient, and more failure-prone. Maturity in software engineering requires prioritizing long-term health over first releases. Preventive practices can slow aging but cannot eliminate it.

Key points

Software aging is inevitable but manageable through disciplined engineering.
Two main accelerants:
Inability to update software as business needs change.
Accumulation of ignorance due to team turnover and poor documentation.
Aging costs: lost competitiveness, increased defects, degraded performance, higher maintenance effort.
Preventive “medicine”: design for change, thorough documentation, frequent code reviews.
Critiques the focus on initial releases and lack of systematic engineering practices.
Documentation is essential despite agile tendencies to downplay it.
Suggests planning for software “retirement” as part of lifecycle management.

Connections

Links to discussions of technical debt and legacy systems.
Resonates with sustainability narratives and maintaining long-lived open source projects.
Contrasts with agile manifesto statements about documentation.
Aligns with DevOps practices emphasizing observability and continuous improvement.

Questions

How to objectively measure software aging across domains?
Which documentation practices balance agility with sustainable knowledge?
How to adapt recommendations for small teams or short-lived projects?
Differences in aging patterns between proprietary and open source software?

Personal reflections

Aging metaphor helps analyze system trajectories, especially with high team turnover.
Highlights challenges seen in both public and private IT projects lacking systematic processes.
“Retirement plan” concept is valuable for interviewing IT managers.
Reinforces importance of documentation and review in case studies.

Detailed notes

Aging compared to humans: inevitable but mitigable via prevention and care.
Focus should shift to system health over first release success.
Aging factors recorded from various talks (timestamps included in original note).
Emphasis on design for change, documentation, code reviews.
Recognize when software becomes unreliable; apply re-modularization and documentation retrofits.
Plan for end-of-support lifecycle as part of responsible engineering.

References

Parnas, D. L. (1994). Software Aging. Proceedings of ICSE 16.
Article PDF: http://www.inf.ed.ac.uk/teaching/courses/seoc/2004_2005/resources/bullet11.pdf
Talk: https://youtu.be/fe8Mp1YOjQI

[[conways-law-birth-1968|Conway’s Law — origins, literature, and team design]]
[[DbC|Design by Contract]]
[[no-silver-bullet-1986|No Silver Bullet — Essence & Accidents]]
[[parnas-modularization-1972|Modularization Criteria — Parnas 1972]]
[[shape-up-2020|Shape Up: Stop Running in Circles and Ship Work that Matters]]

ADR — Architecture Decision Records

Wed, 15 Jan 2025 00:00:00 +0000

ADRs (Architecture Decision Records) are essential documents in software engineering that capture important architectural choices and the context behind them. In an Obsidian vault, ADRs integrate naturally into project documentation.

Why use ADRs?

In long-running projects — such as framework migrations or service changes in Go or Java — decisions change constantly. Without recording why a tool was chosen over another, the team (or even yourself) may forget the reasoning months later, losing the context that justified the choice.

Agile Software Development

Wed, 15 Jan 2025 00:00:00 +0000

Agile is a set of values and principles for software development that emphasizes flexibility, collaboration, and iterative delivery. Rather than following a rigid plan, Agile teams adapt to changing requirements and deliver working software frequently.

What is Agile?

Agile is not a single methodology but rather a philosophy that encompasses various frameworks and practices. The core idea is to break down large projects into smaller, manageable pieces that can be delivered incrementally.

Shape Up: Stop Running in Circles and Ship Work that Matters

Wed, 15 Jan 2025 00:00:00 +0000

Summary

In December 2020 I read several books and papers: The Mythical Man-Month, Design by Contract, Programming with Abstract Data Types, Shape Up, and Domain-Driven Design. Their ideas map directly to problems and solutions I encountered building apps in recent years. The largest recurring gap in real projects is the beginning—how we shape and refine the work—more than the middle or the end. Shape Up gives a concrete way to close that gap in modern teams.

Project-Management on Osmar Petry

Backend Architectures — history, case studies & dogfooding

Summary

Case studies (what they did → why it mattered)

Decision heuristics (when to pick what)

Dogfooding → productization loop

Conway’s Law — origins, literature, and team design

Reference stack

Essence of the law

Historical context & popularization

Key takeaways from the literature review

Review questions

Practical implications

Next actions

Related Notes

Decision-Making Traits of Great Software Engineers

Abstract

Key points

Connections

Questions

Personal reflections

References

Design by Contract (DbC)

Abstract

Key points

Connections

Questions

Personal reflections

References

Related Notes

No Silver Bullet — Essence & Accidents

Abstract

Key points

Connections

Questions

Personal reflections

Detailed notes

References

Related Notes

Software Aging

Abstract

Key points

Connections

Questions

Personal reflections

Detailed notes

References

Related Notes

ADR — Architecture Decision Records

Why use ADRs?

Agile Software Development

What is Agile?

Shape Up: Stop Running in Circles and Ship Work that Matters

Summary