Large Software Projects: How to Approach a Large Software Project

Posted on October 9, 2025  •  7 minutes  • 1325 words  • Other languages:  Español

This post is part of my Large Software Projects blog series .

• My Mindset For Software Projects
  • Good Code Has Two Requirements
  • Not Everything That Can Be Done Should Be Done
  • Fragmented Codebases Lead to High Developer Frustration
  • You Don’t Need to Be an Expert to Make Great Software
  • Project Size ≠ Team Size
  • Sometimes Rewriting Is Worth It
• People That Inspire Me
  • Theo
  • Dreams of Code
  • carykh
  • Eskil Steenberg
• What’s Next?

In the previous post , we established the grim reality: the default setting for large-scale software development is complexity. We’ve collectively normalized architectures that are designed to impress consultants rather than to be maintained by humans. We pay the “complexity tax” daily through slow onboarding, painful debugging, and endless coordination meetings.

But what if the opposite is true? What if the single most sophisticated design choice you can make is to choose simplicity?

The philosophy outlined here is not revolutionary. It’s a return to first principles. It’s about building things that last by making them easy to understand, easy to change, and easy to deploy.

Before we pick a single tool, let me share my approach to building large software projects.

My Mindset For Software Projects

Good Code Has Two Requirements

1. It solves the problem.
2. It doesn’t suck to read.

That’s it. I don’t care if it uses the latest framework or follows every SOLID principle religiously. If it works reliably and the next developer (including future you) can understand what’s happening, it’s good code.

Not Everything That Can Be Done Should Be Done

Just because you can split your application into 47 microservices doesn’t mean you should.

• You probably don’t need a microservices approach (seriously, you probably don’t).
• Don’t over-engineer—at least not without a really good reason.
• That fancy new technology stack? It’s cool, but does it solve an actual problem you have, or does it just look good on your LinkedIn?

The hidden costs of over-engineering:

Think of architecture decisions like seasoning food. A little bit enhances the dish; too much ruins it. The goal is a tasty meal, not to use every spice in your cabinet.

Fragmented Codebases Lead to High Developer Frustration

Imagine playing a game of telephone in a crowded, noisy room. That’s what a hyper-fragmented system can feel like. You’re never 100% sure if your changes in “Service A” will unintentionally ripple through “Service B” on the other side of the organization, even if they shouldn’t have anything in common.

A simple change can quickly escalate into:

• Multiple PRs across multiple repositories.
• Multiple code reviews with different teams.
• Multiple meetings with QA teams.
• Multiple deployment pipelines.
• Multiple points of failure.
• Multiple days of waiting.

Most of the time, if that code lived in a monolith, the change would’ve literally been 10 lines across 2 or 3 files, reviewed in 10 minutes, and deployed before lunch break.

You Don’t Need to Be an Expert to Make Great Software

As Rui Torres said:

You don’t need to be an expert to be a great artist

The same applies to software.

Most of the software you touch every day wasn’t built by people who know every language, framework, and cloud provider. It was built by people who knew how to pick a tool they understood (or could learn quickly), make tradeoffs, and ship.

The true mastery isn’t in knowing every single detail, but understanding how to effectively use and combine abstractions to solve real-world problems. Focus on building and learning; the “expert” label will follow, not precede, your accomplishments.

Project Size ≠ Team Size

As Frederick P. Brooks, Jr said:

Adding manpower to a late software project makes it later.

The size of a project should NOT be proportional to the tech team behind it.

Adding more people to the mix only creates more noise, more meetings, more coordination overhead, and more opportunities for miscommunication.

Some of my favorite examples of huge projects with small teams:

Small, focused teams can build incredible things when they’re not spending half their time in coordination meetings.

Sometimes Rewriting Is Worth It

If you spend more time trying to understand what the code is doing than actually building new features, if the tech stack is so outdated that you can’t find documentation anymore, if every change feels like defusing a bomb… maybe it’s time for a fresh start.

Obviously, this isn’t always the right call. Joel Spolsky’s famous article about Netscape is required reading here. But the decision shouldn’t be “never rewrite” or “always rewrite”—it should be based on honest evaluation:

• Can new developers become productive in a reasonable timeframe?
• Is the current codebase preventing you from meeting business needs?
• Do you understand the problem domain better now than when the original was written?
• Can you rewrite it without falling into the same traps?

Sometimes the answer is yes, and that’s okay.

People That Inspire Me

Before we dive into building, I want to highlight the voices that shaped my thinking. These aren’t just random YouTubers I watch—they’re people who embody the principles I’ve been advocating for. They prove that great software comes from clear thinking, not from complexity for complexity’s sake.

Theo

I discovered Theo (@t3dotgg) through his “Do you REALLY need a backend?” video back in 2022.

You may not agree with all his takes or like his upfront character, but you cannot deny he has solid knowledge and a genuine talent for creating “nerd” content that’s both entertaining and educational.

His willingness to challenge common assumptions resonates deeply with the philosophy I’m advocating here. He reminds me that serious tech discussions don’t have to be dry, and that sometimes the best solution is the simpler one you overlooked.

Dreams of Code

Dreams of Code creates content that focuses on practical development tools and concepts rather than chasing trends.

While he primarily works with Go (a language I haven’t used), his videos transcend language-specific syntax. What matters is ow he explains fundamental concepts in ways that apply regardless of your stack.

His approach reinforces my belief that understanding core principles is more valuable than being married to specific technologies.

carykh

carykh (Cary Huang) was exploring AI, genetic algorithms, and evolutionary simulations back in 2018—long before AI became the buzzword it is today.

What inspires me most isn’t just his technical foresight, but his approach: building projects as a solo developer, explaining complex concepts through engaging visuals, and doing it all with genuine enthusiasm.

His work proves you don’t need a research lab or a huge team to explore cutting-edge ideas. Sometimes you just need curiosity, dedication, and a willingness to experiment.

Eskil Steenberg

The one that really pushed me from “idea” to “let’s actually do this” is Eskil Steenberg ’s video, “Architecting LARGE software” (the thumbnail for this post is a direct homage!).

The video itself is dead simple: just a dude, a screen, and C code. No fancy PowerPoints, no slick graphics—just raw, unadulterated wisdom. What makes it powerful is how Eskil demonstrates that large software doesn’t have to mean complicated software.

What’s Next?

In the next posts, we’ll stop philosophizing and start building. I’ll walk through the decisions, explaining the tradeoffs, and keeping it simple.

Let’s build something great. 🚀

Next Blog: Large Software Projects: Choosing the Right Tools