In 2023, I landed my first job in IT. A dream come true: me, a fresh college graduate, hired by a company with 20 years of history. I was happy and naively believed I'd soon figure everything out and become a great manager.
Reality was harsher.
We all worked under the same Agile standards (which changed constantly), yet my colleagues' results varied dramatically. Some delivered brilliant products; others produced endless unfinished projects.
I couldn't figure out the secret. Until I looked inside the successful teams.
The secret was both simple and complex. In these teams, managers, analysts, and developers spoke the same language.
They didn't blindly follow rules - they created their own, where business requirements immediately translated into architecture that developers understood. Developers didn't just "write code"; they were genuinely interested in creating something new because they understood why.
This article is a conversation with my past self. With the person who just entered IT and kept hitting the wall of miscommunication between departments.
Now, having worked as both a programmer and a systems analyst, I've developed a system of principles that helps establish this "common language."
How This Idea Was Born
Initially, I envisioned a purely technical solution. A prototype framework for Go called Monarch(Monolith + Architecture). Too much, I know, but the goal was different: I wanted AI and templates to generate the boring, repetitive code, tests, and structures for developers. So that on urgent projects (needed "yesterday"), SOLID principles wouldn't get thrown out the window but would be followed by default.
But the deeper I dove into the technical implementation, the clearer it became: the problem wasn't language or the code. The problem was how we agree on what to write.
The principles I wanted to embed in the code turned out to be broader than any architecture. They touch on the entire product development process.
These aren't abstract tips - they're patterns I discovered while working in different teams, both good and bad, on interesting projects and not so.
Here are 7 principles that unite managers, analysts, and developers. If your team doesn't use them, you're just passing bugs back and forth like a hot potato :^)
1. The "Untestable Code Doesn't Exist" Principle
The Problem: The manager doesn't write test cases because they "don't understand the business." The developer doesn't write tests because "the code is complex." The tester doesn't know what exactly to check.
The Solution:
If you can't come up with a test case for your task, you don't understand the task.
Manager/Analyst: Your pain point is vague requirements. Turn them into a testing scenario. If the scenario doesn't come together, the requirement is dead.
Developer: Forget the phrase "This can't be tested." Code coverage isn't a checkbox for the QA department. It's your get-out-of-jail-free card for a good night's sleep.
Rule: If code can't be covered by at least one testing method (unit, integration), that code doesn't belong in the product. A chef wouldn't serve a dish they haven't tasted. Don't serve code you haven't "tasted" with tests.
2. The "Why?" Principle
The Problem: Developers are told how to do something, but not why. As a result, they do exactly what they're told, burying technical debt in the architecture because they can't see the big picture.
Rule:
Business goals and their potential consequences must be understood by all participants. A good developer differs from a mediocre one not by typing speed, but by the ability to say: "This business idea will kill database performance in a month." But they can only say that if they know the idea, not just a ticket in Jira.
3. The "Build vs. Buy" Principle (Don't Reinvent the Wheel? Actually, Sometimes Do)
Rule: Minimize dependencies on third-party components.
The Essence: We don't add a library or service "because it's trendy" or "because competitors use it." We write code or implement a solution only if it directly impacts profit or critically addresses a unique need. Someone else's library is a black box. You never know when it'll explode.
4. The "Chef" Principle (Availability of Tests)
I've worked at many companies. Everywhere I heard the mantra: "If the code is hard to cover with unit tests, don't bother, don't write them."
Folks, that's the road to hell.
The rule should be harsh: "If you can't write tests, don't write code."
Yes, it's ruthless. Yes, developers are already overloaded. But responsibility for quality can't be shifted entirely to QA. The tester is the last line of defense, not the only one. If a chef cooks garbage hoping the dishwasher will clean it up, the restaurant will close.
Write clean code. Know how your code works and the legacy code around it. Then the tests will come naturally.
5. The "Stay in Your Lane" Principle
Every participant in the process should do exactly their job: no more, no less.
Sounds obvious? Now think about how many times an analyst meddled in architecture, or a developer started rewriting business requirements to make them "prettier" from a technical standpoint. Chaos begins where roles blur without permission.
6. The "No One Is Irreplaceable" Principle (Bus Factor)
Ever had this happen: a key developer leaves, and the code turns into a pumpkin? No one can understand it, support grinds to a halt.
A True Story.
In one of my teams, there was a legendary developer. He seemed to think in bytecode. A whole media storage subsystem rested on his shoulders. He was irreplaceable. And trouble came from where we least expected - he went on vacation.
I had what seemed like a simple task: change how images were displayed in the product catalog. But the frontend depended on his "black box" image compression system. The code was so unique (read: unreadable) that no one could figure it out. A project worth hundreds of hours and the client's budget stalled for two weeks.
By the time the "irreplaceable" one returned, the client's department had already been laid off. The feature was finally implemented, but there was no one left to appreciate it, let alone maintain it. The code turned into a pumpkin, and the money turned into zero.
Rule: Changes in the team (departure, vacation, illness) should not affect code quality or the ability to modify it. Code must be transparent enough that a new person can step in without crying. If the code relies on the charisma of one senior developer, it's not an asset - it's a time bomb.
7. The "Unified Language" Principle (Unified Architecture)
This is about architecture as a whole, not just SOLID, DRY, or KISS. Your company should have a unified architectural pattern.
And it doesn't matter if you write in Go, Java, or Ruby. Your Java developer should be able to open Go code and understand the logic because the project structure is the same everywhere.
Architecture should be as simple as possible. Onboarding new team members should take days, not months. If understanding the code requires being "born" into the company, your architecture is killing your business.
Conclusion
I started this article thinking I wanted to teach managers and developers to speak the same language. In the process, I realized: Monarch is an attempt to embed human communication into technical rails.
Yes, the principles I've described were born from code. From the pain of testing, from dependencies, from the departure of key developers. But each one ultimately boils down to a simple rule: respect the person who will work with your code after you.
I'm not claiming MONARCH is the ultimate truth. It's a living organism. Add to it, adapt it to your context.
The only thing I ask you to preserve is the core idea: We write code for machines, but also for people
I'd love to hear in the comments what communication challenges you've faced. Let's think about this together! :)
Top comments (0)