Principles of Software I Believe In

I’ve spent over a decade building systems that work. Not technology demos but real systems.

What have I learned? Most flashy tech advice is either naive or only works in unicorn-level environments. There is no single recipe for success. The rest of us need principles that scale with reality.

These aren’t theoretical ideals; they’re hard-won lessons. Here’s what I keep returning to, even though each system is different and may require some rule-breaking. I’m not a fanatic, but I aim to design the best systems under the circumstances.

🔹 Modular architecture isn’t optional.

Complexity always grows. You either manage it proactively or drown in it reactively. Modularity isn’t about buzzwords — it’s about resilience. It allows you to isolate risk, replace parts without fear, and debug what’s happening. That’s not a luxury; that’s survival.

One of the first large systems I worked on was in telecom. It wasn’t modern — no Zephyrs, zero-MQ, boosts, or tailored Yocto or dockers. However, it was modular enough to manage. It had clearly defined interfaces, and despite its complexity, it was maintainable. That modularity is what made it survivable and expandable. Up to a certain point, products were evolutionary, not breakaway designs. It was better structured than I’ve seen in many newer companies.

🔹 Reuse is a product, not an afterthought.

Reusable assets aren’t just good code. They’re code that is easy to understand, onboard, and trust. Documentation and specification that helps, not hinders. Matching requirements and use cases. Naming that makes sense. Tests that are not superficial. If no one wants to touch it, it’s not reusable — it’s radioactive.

Reusable means you think about onboarding and document why, not just how. I’ve worked on platforms where 80% of the work was digging through past implementations. That’s not development—that’s archaeology.

🔹 Loose coupling > perfect integration.

Tight integration can be tempting when moving quickly. However, if you don’t want to be the only one who understands the system, focus on decoupling. It is the only way to scale teams, implement changes, and maintain sanity in the long run.

Loose coupling offers flexibility. You can replace one component without dismantling the rest. I’ve witnessed too many critical paths relying on tightly woven black boxes. It’s a nightmare, especially when onboarding new developers or rapidly scaling up.

🔹 DRY, clean, and solid — with common sense.

I believe in clean code but don’t believe in cult-like adherence. Sometimes, duplication is easier to understand than abstraction, and simplicity often beats cleverness. I prioritize writing code for people first and machines second.

DRY doesn’t mean “forcing everything into a framework.” It means avoiding meaningless repetition when it introduces risk. Clean code doesn’t mean flawless — it means readable. And solid doesn’t equate to over-engineered. These principles should minimize entropy, not increase it.

🔹 Design for the whole lifecycle.

Code is the easy part. Can you:

• Specify it SMART-ly?

• Debug it at 2 AM when alerts go off?

• Onboard someone to it in a week?

That’s what I optimize for.

I’ve seen systems where logging and testing were considered afterthoughts — and those teams paid for it later. They moved quickly at first but ended up wasting time in endless triaging. Systems that are easy to test and monitor are more cost-effective in the long run. They scale with less drama.

🔹 Startups move fast. And they should.

I understand the urgency of entering the market. In the early stages, you validate an idea rather than constructing a cathedral. You don’t require extensive architecture before attracting your first users.

However, there’s a middle ground. Moving quickly while retaining a few strategic provisions that allow for evolution without necessitating a complete overhaul later is feasible. A little foresight today can prevent the unwelcome rewrite that no one wishes to finance tomorrow.

You don’t need perfect. You need change-ready.

🔹 Ownership and E2E responsibility aren’t just nice-to-haves.

They represent the difference between teams that ship and those that stall. I develop organizations and systems that encourage clarity of ownership, defined interfaces, and shared accountability. If you own it, you should be able to change it — and take pride in it.

Engineers should feel like owners, not mere ticket robots. This involves having a say in architectural decisions and being accountable for their function and overall outcome. Moreover, it means empowering them with tools and autonomy instead of burdening them with layers of approval chains.

🔹 Tradeoffs deserve daylight.

Every decision conceals a cost. Whether it’s a missed test, a fragile dependency, or a temporary hack, I want highlighted tradeoffs—not to blame but to inform. So we can build with our eyes open, not with crossed fingers.

Too many technical mishaps arise from unspoken assumptions. We prioritized speed over stability, overlooked monitoring, and avoided tests because “the deadline was tight.” That’s acceptable—if it’s clear to everyone. But too often, it’s brushed aside until it explodes.

I have witnessed projects thrive because one engineer had the bravery to say, “This part is fragile. Let’s document that.” Transparency is not only good ethics; it is also sound engineering.

A few more things I believe, without compromise:

• A tight feedback loop between PMs and devs is worth more than any Gantt chart.

• Communication is a technical skill.

• It’s not just about “can we build it?” It’s about “what happens when it breaks?”

• Responsibility without visibility is cruelty. Responsibility with visibility is alignment.

• Architecture isn’t about tech choices. It’s about enabling change with confidence.

If this resonates.

These principles have served me across sectors. They help me stay flexible while delivering under time, budget, and regulation constraints.

If you’re building systems that need to last — or want to avoid painting yourself into a corner — these are the conversations I’m here for.

🔗 https://janmatus.com

Let’s make software that matters.

About the author

Jan Matus is a systems architect with 13+ years of experience in high-availability, embedded, and distributed systems. He builds software that’s modular, maintainable, and actually works under pressure. His principles are shaped by real-world delivery — not theory.

🔗 start.janmatus.com — Explore more or get in touch.