Architecture

Build for the Maintainer, Not the Moment

Dec 30, 2024

Webb’s view of the Sombrero galaxy reveals intricate dust patterns, symbolizing the clarity and complexity of building resilient, maintainable systems.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” —John Woods

A concise yet impactful set of software engineering principles has recently captured attention online, sparking meaningful discussions about contemporary development practices. These 17 “rules” distill decades of expertise into insights that help leaders build resilient, scalable, business-ready software.

Their appeal lies in addressing challenges universal to software engineers and technology leaders: mastering complexity, enhancing collaboration, and promoting long-term sustainability. Let’s dive into the list.

At first glance, these rules seem simple, but their real value lies in sparking deeper reflection on how we build software, collaborate, and balance technical decisions with business priorities. Let’s explore what they mean for leaders and teams.

Maintainability Over Cleverness

Rule #3, “Every line of code you write is a liability,” shifts how we think about software. Code represents potential value, but it’s also a responsibility. Every feature increases complexity, requiring ongoing maintenance, testing, and eventual refactoring. Overengineering costs become glaringly apparent during emergency 3 a.m. calls (#1), where needlessly clever abstractions (#0) hinder swift problem resolution.

Simplicity trumps cleverness. Maintainable systems fail gracefully, recover quickly, and are easy for any team member to update. Rule #11, “Always build for maintainability,” underscores that resilient, adaptable systems deliver greater value than short-term wins. Prioritizing maintainability protects the software and the business, minimizing risk and downtime.

Strategic Compromises, Better Software

Rule #2, “Everything is a trade-off,” captures the essence of software engineering: balancing competing priorities. Teams frequently face decisions such as:

  • Performance vs. Readability: Optimizing for speed can obscure code clarity, complicating future work.

  • Build vs. Buy: Dependencies save development time but can introduce risks like security vulnerabilities or long-term maintenance challenges.

  • Feature-rich vs. Maintainable: Adding features for niche use cases often burdens the entire system.

Leaders guide teams to evaluate these trade-offs with a long-term view. Rule #16, “Ship early, iterate often,” works best with thoughtful planning and stable deployments. Short-term wins matter, but not if they compromise long-term stability.

Collaboration Fuels Great Code

Software development depends as much on teamwork as on technical expertise. Rules like #4 (“Document your decisions and designs”), #8 (“Write clear commit messages”), and #10 (“Code reviews spread knowledge”) emphasize the importance of transparent communication. These aren’t mere tasks—they build trust, reduce silos, and strengthen collaboration.

Coding standards (#7) enhance teamwork by creating shared expectations and minimizing unnecessary debates. Even the best technical solutions fail when they can’t be understood, maintained, or extended by others.

Continuous learning fosters growth and flexibility. Rule #9, “Never stop learning new things,” and Rule #12, “Ask for help when you’re stuck,” encourage developers to seek advice and share their expertise. Teams that embrace collaboration and knowledge sharing solve problems quickly and build strong relationships.

Facing Software’s Hard Truths

Some principles reflect the unchanging realities of software engineering:

  • Fix root causes, not symptoms (#13): Systems evolve as users do, requiring updates and maintenance. Addressing root issues ensures stability and prevents recurring problems.

  • Software is never completed (#14): Systems require updates to meet evolving needs even after release.

  • Estimates are not promises (#15): Deadlines are educated guesses, not guarantees. Transparent communication with stakeholders avoids frustration and fosters trust.

Acknowledging these truths strengthens relationships between technical teams and the business, fostering alignment and shared success.

Creating Systems That Last

The shift from immediate results to sustainable development requires intentional leadership. Leaders empower teams by:

  • Fostering knowledge sharing: Encourage documentation and collaborative reviews to build shared understanding.

  • Encouraging continuous learning: Normalize growth and requests for help to build a supportive culture.

  • Setting realistic expectations: Educate stakeholders on the iterative nature of software and estimation challenges.

  • Prioritizing simplicity: Design intuitive systems that reduce long-term complexity.

  • Building trust: Foster transparency and shared standards to cultivate reliability and accountability.

Sustainable success in software development isn’t measured by velocity but by systems that:

  • Adapt reliably to change

  • Are easy to maintain

  • Enable innovation

  • Deliver consistent business value

  • Foster collaboration and team growth

Empowering Teams to Succeed

As technology leaders, we can champion these principles and cultivate this mindset. By fostering open communication, guiding teams through trade-offs, and preparing for challenges, we create an environment where developers thrive. These rules aren’t just technical—they form the foundation for meaningful, lasting impact.

Whether mentoring junior developers, leading agile teams, or managing enterprise organizations, these principles serve as a compass—guiding success in the systems we build, the teams we inspire, and the value we deliver.

Let’s talk about your platform challenge.

If your organization is navigating scale under regulatory complexity—or making the shift from reactive delivery to resilient platform engineering—I’d welcome the conversation.

3. Nashville Skyline
1. Nashville Skyline
3. Nashville Skyline
1. Nashville Skyline
3. Nashville Skyline
4. Nashville Skyline
2. Nashville Skyline
4. Nashville Skyline
2. Nashville Skyline

Let’s talk about your platform challenge.

If your organization is navigating scale under regulatory complexity—or making the shift from reactive delivery to resilient platform engineering—I’d welcome the conversation.

3. Nashville Skyline
3. Nashville Skyline
3. Nashville Skyline
3. Nashville Skyline
3. Nashville Skyline
4. Nashville Skyline
2. Nashville Skyline
4. Nashville Skyline
2. Nashville Skyline

Let’s talk about your platform challenge.

If your organization is navigating scale under regulatory complexity—or making the shift from reactive delivery to resilient platform engineering—I’d welcome the conversation.

3. Nashville Skyline
1. Nashville Skyline
3. Nashville Skyline
1. Nashville Skyline
1. Nashville Skyline
4. Nashville Skyline
2. Nashville Skyline
4. Nashville Skyline
2. Nashville Skyline