SDLC Overview: Changing Software From an Artform to an Engineering Discipline

Changing software from an artform to an engineering discipline

I have watched codebases erode and watched engineers burn hundreds of hours debating irrelevant details. From bike-shedding to gatekeeping, the team you build will make or break your organization.

"You should be more concerned with bringing the wrong players onto your team than with getting the best players. You may lose to a great player recruited by a rival team once a year — but if you have the wrong player on your team, they'll beat you every day."
— a coaching maxim I've never forgotten

So the question becomes: how do we help our players become the right players? (Ted Lasso built an entire show around that question, and it's a good one to sit with.)

Team members roughly sort into a trust-versus-skill matrix, and it's worth being honest about where people actually fall on it. Low-trust, high-skill team members will destroy a team from the inside. High-trust, mid-tier-skill team members, on the other hand, are often the most valuable people in the room.

If you're an engineer reading this, you've probably occupied more than one of those quadrants at different points in your career — the environment we work in shapes how we navigate stress and how we deliver results. AI agents, when designed well, can see the cruft and the quality of the code underneath the surface. They should also let us collaborate and identify value that maps to measurable ROI more effectively than the scrum systems we grew up with.

Rules and practices for building secure, stable, scalable codebases

Outline — full expansion pending

This is the working list of topics this series will dig into, one at a time:

1. Cognitive load as a first-class concept.
2. Deriving meaning from descriptive variable names.
3. Death by a thousand lines of code — a case for keeping files under 500 lines, and never above 1,000.
4. Granularity nightmares — function-based coding patterns that are really just Object-Oriented Design hiding behind class modules, and still manage to violate the Single Responsibility Principle.
5. Code reuse as a guardrail, not a dogma.
6. Cyclomatic complexity — why "functional" code often isn't as clean as it looks, why cyclomatic complexity maps directly to cognitive load in large mental models, and why junior and mid-level developers gravitate toward functional patterns (easy to ship unit tests and say you ran them; easy to keep shipping low-value changes; and just as easy to quietly ship cruft). See Martin Fowler's writing on programming style for more.
7. Software design patterns — a short history of stable systems and the books worth reading.
8. Software planning — how Agile actually transformed software: the MVP, the sprint, feature prioritization, research spikes, blocker identification, work distribution, and how risk planning improves a team's cadence through divide-and-conquer tactics.
9. Software development from proof-of-concept to production rollout:
   • Mocks, loose types, and lightweight testing for fast iteration on ideas rather than the shape of the code.
   • Why type systems exist for hardening and validation.
   • Test-Driven Development vs. Test-Driven Hardening.
   • Different SDLC lifecycles.
   • What QA's real job actually is.
   • DevSecOps vs. DevOps, and why it matters.
   • Integration testing, and how Nanobars reduce risk and improve quality.
   • Performance testing, and how Nanobars pressure-test infrastructure before production.
   • Production validation automation with Nanobars.