Improving Software Development Flow

The inverse Conway maneuver shapes teams and interactions to support the desired architecture. Domain-driven design recognizes that different subdomains require different approaches, while terminology must remain consistent within its context. Boundaries therefore cannot be chosen solely from code size; they need to reflect the business model and ownership being separated.

An oversized monolith concentrates complexity internally, while too many tiny services move complexity into their interactions. Deep modules provide a way to look for concise interfaces that hide substantial implementation detail. For analytical data, the talk discusses Data Mesh through domain ownership, data products, self-service infrastructure, and shared interoperability rules. These approaches connect technical boundaries with people's work and data consumers' needs.

Instead of continually pushing more tasks onto teams, work should be visible and pulled when capacity becomes available. Excessive work in progress, unknown dependencies, unplanned work, conflicting priorities, and neglected improvements slow the flow. Throughput, elapsed time, and blocked items help reveal the causes of delay. Metrics support realistic expectations and process changes rather than serving only as reports.

Engineering practices include continuous delivery, testing, and regular attention to technical problems. Tinkoff's Spirit platform illustrates shared build infrastructure, quality checks, managed services, and operational tools. Common capabilities reduce repeated work across teams. Strategic programming also means avoiding unnecessary complexity introduced to finish one task faster, only to make every subsequent change harder.

Google's Project Aristotle supports the discussion of psychological safety, while Westrum's typology compares organizational responses to problems. The author retains the limitations: Google's findings concern the teams studied, and a statistical association between culture and performance does not establish causation. In engineering, postmortems apply this perspective by examining incident conditions and preventing recurrence rather than searching for someone to blame.

The final ideal is customer focus. Completed work should be connected with business goals, service availability, and users' ability to accomplish their tasks. Improving the delivery pipeline is valuable only when it serves the right product. Discussions of speed should therefore start with the intended outcome and connect it with architecture, workflow, and the conditions in which teams identify and correct mistakes.