Control lives on the transitions; between them nobody watches.
Anton Brilliantov, a software engineer specializing in PHP/Symfony and Go, is carving a monolith into microservices. He's documenting this process, focusing on the order of work: how a wish transforms into requirements, then a contract, then tasks, and finally a specification. This series explores where checks and balances are applied and, crucially, what kind of supervision he has stopped practicing.
The Lifecycle of a Feature: From Wish to Specification
The journey of a software feature, as outlined by Brilliantov, follows a structured path designed to ensure clarity and manageability. It begins with a nebulous 'wish' – an idea or a desire for a new capability. This wish is then refined into concrete 'requirements,' detailing what the feature must accomplish. These requirements are formalized into a 'contract,' often expressed through a schema, which acts as a definitive agreement on the feature's behavior and interface. From this contract, specific 'tasks' are generated for the development team. Finally, each task is elaborated into a detailed 'spec,' providing the granular instructions for implementation.
This structured approach emphasizes the importance of formalizing each step. The contract, in particular, serves as a critical checkpoint. It’s not just a technical document; it’s a shared understanding between stakeholders and developers. By defining the contract in a schema, Brilliantov ensures that there is an unambiguous, machine-readable representation of the expected behavior. This reduces the likelihood of misinterpretation and provides a clear target for the subsequent tasks and specifications.
The Philosophy of Gatekeeping: Control at Transitions
The core of Brilliantov's methodology lies in his observation that 'control lives on the transitions; between them nobody watches.' This philosophy shifts the focus of supervision from the day-to-day minutiae of individual tasks to the critical junctures where one stage of development transitions to the next. Instead of micromanaging developers as they work on their assigned tasks, the emphasis is placed on ensuring that the output of one stage correctly and completely meets the inputs required for the subsequent stage.
Think of it less like a factory floor where every worker's action is constantly monitored, and more like a series of quality control gates at the end of each assembly line. A worker might be given a blueprint (the spec) and the freedom to build a component (the task) without constant oversight. However, before that component can be integrated into the larger product, it must pass through a rigorous inspection point (the transition gate) that verifies it meets the contract's specifications. This approach trusts developers to execute their tasks efficiently while ensuring that the overall process remains on track and that integration points are solid.
This method aims to foster autonomy and trust within the development team. By removing the pressure of constant micromanagement, developers can focus on problem-solving and efficient execution. The 'gates' act as the primary mechanism for maintaining quality and alignment. These gates are not arbitrary hurdles but are strategically placed checkpoints that validate the progress made in the preceding phase. If a task is completed, it's reviewed against the contract and spec. If the contract is defined, it's checked against the requirements. This ensures that any deviation or issue is caught early, precisely at the point where it impacts the next phase of work.
Practical Application: PHP Monolith to Go Services
Brilliantov's current work involves breaking down a PHP monolith into Go services. This complex undertaking provides a practical proving ground for his gatekeeping philosophy. The transition from a monolithic architecture to a microservices one requires meticulous planning and execution, especially concerning inter-service communication and data contracts. The defined contracts and specifications become even more critical when services need to interact reliably.
For instance, when a 'wish' for a new feature emerges, it must first be translated into clear requirements for the new Go service and its interaction with the remaining monolith or other services. This then solidifies into a contract, likely defined using something like OpenAPI or Protocol Buffers, detailing the API endpoints, request/response structures, and data formats. This contract acts as the gate. Once the Go service developers have implemented their tasks according to their specifications, the service's API is tested rigorously against this contract. Any discrepancies are identified and rectified at this transition point, before the new service is deployed or integrated further.
The advantage here is twofold. First, it allows the PHP team to continue evolving the monolith without being blocked by the Go service development, and vice versa, as long as the contract is adhered to. Second, it provides clear metrics for progress and success. The 'gates' are not subjective judgments but objective verifications against the agreed-upon contract. This systematic approach helps manage the inherent complexity of decomposing a large system, ensuring that the pieces fit together as intended without requiring constant, granular oversight of every developer's work.
The Human Element: Trust and Autonomy
The underlying principle of Brilliantov's approach is a profound trust in the capabilities of his engineering team. By shifting control to the transitions, he empowers developers to own their tasks and specifications. This autonomy can lead to increased job satisfaction, higher quality output, and a more engaged workforce. Micromanagement, conversely, often stifles creativity, breeds resentment, and can lead to a 'tell me exactly what to do' mentality, which is detrimental to innovation and problem-solving.
The success of this 'gates, not micromanagement' strategy hinges on clear communication, well-defined contracts, and robust testing at each transition point. It requires a cultural shift towards accountability for outcomes rather than adherence to process. When developers understand the 'why' behind the requirements and contracts, and they have the freedom to figure out the 'how' within their tasks, they are more likely to produce excellent work. The gates ensure that this freedom doesn't lead to chaos, but rather to a more efficient and effective development pipeline.
This model also has implications for team structure and leadership. Leaders become facilitators and architects of the process, ensuring the gates are well-defined and appropriately staffed, rather than taskmasters. They focus on the flow and health of the overall system, trusting their teams to manage the individual components. The surprising detail here is not the reduction in supervision, but the *shift* in its nature – from intrusive oversight to strategic validation at key integration points.